Over a million developers have joined DZone.

Concern Around Mapping and Discussing Shadow Mobile APIs Shows Signs of an Imbalance

It's easy to see what web service calls your mobile app is making, so is it better to be transparent about your API?

· Mobile Zone

Visually compose APIs with easy-to-use tooling. Learn how IBM API Connect provides near-universal access to data and services both on-premises and in the cloud, brought to you in partnership with IBM.

After I've talked about my mapping of the public, and mobile APIs with various folks over the last couple of months, I can usually put folks into one of three camps 1) they do not understand what the hell I am talking about and could care less, wishing the geek dude would shut up 2) thinks its a really interesting idea and worth exploring and discussing, or 3) they express concern, and liken it to scraping, and even hacking. I can understand folks not caring because they don't grasp it technically, but I do not fully yet grasp why people express concern and think it's wrong that I am mapping out, and wanting to discuss this layer of our digital world(s).

As I was working with the new features in Stoplight.io last night, profiling some of the applications on my mobile phone's desktop, I spent some more time thinking about this topic. I find it fascinating that companies do not consider the APIs they use to drive mobile applications as public infrastructure when I can sit in my living room, and engage with them over the public Internet. I find it even more fascinating that some folks consider what I do as contributing to securing problems, when I map these APIs out, share and discuss them on the open Internet. 

I am not intercepting anyone's traffic, or hacking anyone's systems. I am simply using a publicly available mobile application I found in the app store, and I am interested in understanding how leading companies are designing their APIs. Next I'm interested in discussing how these APIs compare with the same companies public API infrastructure, or possibly why a company does not have a publicly available API program. After that, I am also looking for a better understanding around which of my life bits (and others) are being transported as part of my daily mobile app usage. 

I've heard many arguments on why this public infrastructure definition should remain private, like the data that is being transported over it. Ranging from security concerns, all the way to that users should just be thankful the service is available, and its the companies right to do what they think is right, and its the users right to not use the service--markets and all that stuff. While I think this may apply in some situations, there are many scenarios where users are uninformed, being straight up lied to, or do not have the agency to make a decision to leave a platform or application. 

My focus in this discussion centers around consumer facing mobile, and device based apps. I'm not talking about business to business integrations, government services, and other digital infrastructure, I'm talking about the ubiquitous mobile apps that the average smartphone user is being pushed. This is the layer of the digital economy that is being built on the exhaust of the average mobile and Internet consumer. This is one reason why many folks do not want to disclose and discuss this shadowy layer of the application, IoT, and ultimately API economy--they hope they will get their piece of the action some day, and do not want to rub the money people wrong by rocking the boat.

While I think money motivates a lot of the thinking that occurs, but I can't help but feel that a narrow focus is also a part of it. In the mad rush to be the next big thing, a lot of things get kicked to the side. Things like security and privacy get overlooked, or compromised, and a security through obscurity strategy is installed by default, which works just fine until...well it doesn't. If the bad guys want to know your infrastructure, all they have to do is turn on Charles Proxy like I did, and route your computer, mobile, and tablet devices through it. Hiding the blueprint for your APIs, that you are using over the open Internet, and being afraid to discuss them publicly is not good business, and doesn't address the security and privacy concerns everybody who operates on the open Internet will face at some point in the future.

I feel like having people in my world express concern to me about using Charles Proxy to map this world of APIs demonstrates there is an imbalance in the game. While I am looking to discuss the business that's going on in this layer, my priority is security and privacy around this very public infrastructure. I get that many of you have concerns about giving away your "not so" secret sauce, or that disclosing what goes on in this layer will hurt your bottom line, I'm thinking that discussing security and privacy should be prioritized, and not discussing them will eventually hurt your bottom line worse. 

I'll end my rant there. I'm interested in gathering more of these concerns, as I continue to map out this layer of our digital world. Like the rest of my API research, I'm finding that I'm learning a lot about the API design strategy of leading mobile application providers, and a better understanding of how APIs are fueling the mobile economy, which is something I am also looking to extend to the emerging device economy.

The Mobile Zone is brought to you in partnership with Strongloop and IBM.  Visually compose APIs with easy-to-use tooling. Learn how IBM API Connect provides near-universal access to data and services both on-premises and in the cloud.

api,process automation,zapier

Published at DZone with permission of Kin Lane, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}