Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Why I Still Believe in APIs: The 2017 Edition

DZone's Guide to

Why I Still Believe in APIs: The 2017 Edition

In 2017, I don't think I need to spend much time convincing people to do APIs. They are already doing this. There is more going on than I can keep track of.

· Integration Zone
Free Resource

Discover how Microservices are a type of software architecture where large applications are made up of small, self-contained units working together through APIs that are not dependent on a specific language. Brought to you in partnership with AppDynamics.

As I approach my seventh year as the API Evangelist and find myself squarely in 2017, I wanted to take a moment to better understand and articulate why I still believe in APIs. To be the API Evangelist, I have to believe in this or I just can't do it. It is how my personality works; if I am not interested or don't believe in something, you will never find me doing it for a living, let alone as obsessively as I have delivered API Evangelist.

What Do APIs Mean To Me?

There are many, many interpretations and incarnations of "API" out there. I have a pretty wide definition of what an API is, one that spans the technical, business, and politics of APIs. API does not equal REST, although it does employ the same Internet technologies used to drive the web. API is not the latest vendor solution or even standard. The web delivers HTML for humans to consume in the browser and web APIs deliver machine-readable media types (XML, JSON, Atom, CSV, etc.) for use in other applications. When I say applications, I do not just mean the web, mobile, and devices applications — I mean other applications, as in the action of putting something into operation. An API has to find harmony between the technical, business, and political aspects of API operations and strike a balance between platform, third-party developer, and end-user needs, with every stakeholder being well informed along the way.

I Still Believe Early My API Vision

When I close my eyes, I still believe in the API vision that captured my attention in 2005 using the Delicious API, again in 2006 with the Amazon S3 and EC2 APIs, and with the Twitter API in 2007. Today, I better understand that a significant portion of this early vision was very naive and too trusting in the fact that people (API providers and consumers) would do the right thing with APIs. APIs use Internet technology to make data, content, and algorithms more accessible and observable, securely using the web. APIs can keep private information safe, and ensure only those who should have access do. I believe that an API-first approach can make companies, organizations, institutions, and government agencies more agile, flexible, and ultimately more successful. APIs can bring change, and make valuable resources more accessible and usable. When done right.

APIs Are Not Going Away or Being Replaced

Yes, many other technologies are coming along to evolve how we exchange data, content, and algorithms on the web, but doing this as a platform in a more open, transparent, self-service, and machine-readable way is not going anywhere. I try not to argue in favor of any technological dogma like REST, Hypermedia, GraphQL, and beyond, but I do try to be aware and make recommendations of the benefits, and consequences along the way. Having a website or mobile application for your business, organization, institution, government agency, and often times individuals isn't going to go away anytime soon. Neither will sharing the same data, content, and algorithms available for use in applications in a machine readable way, for use by third-party groups using Internet technology. The term API has gained significant mindshare in the tech space, enjoys use as an acronym in the titles of leading news publications, and has taken root in the vocabulary of average folks, as well as the entrepreneurs, developers, and technology companies who helped popularized the term. 

APIs Are Not Good, Nor Bad, Nor Neutral; People and Companies Are

APIs get blamed for a lot of things. They can go away at any time. They are unstable. They are not secure. The list goes on and on, and many also like to think that I blindly evangelize that APIs will make the world better all by themselves. I do not. APIs are a reflection of the individuals, companies, organizations, institutions, and agencies that operate them. In the last seven years, I have seen some very badly behaved API providers, consumers, and companies who are selling services to the sector. Going forward, I will never again be surprised again by how badly behaved folks can be when using APIs, and the appetite for an API-driven surveillance economy that is fueled by greed and fear. 

API Specifications, Schema, and Scopes Are The Most Critical Part

I track on over 75 stops along my definition of the API lifecycle, and many of them are very important, but my API definition research, which encompasses the world of API specifications, schema, and scopes, will play the most significant role in the future of the web, mobile, and connected device technology. This is why I will be dedicating the majority of my bandwidth to this area in 2017 and beyond. Other areas will get attention from me, but API specifications, schema, and scopes touch on every other aspect of the API sector, as well as almost every business vertical driving our economy today. Industry level standards like PSD2 for the banking industry will become clearer in coming years, as a result of the hard work that is going on right now with API definitions.

Help Ensure the Algorithms That Are Increasingly Impacting Our Lives Are Observable

APIs provide access to data and content, but they also provide some observability into the black box algorithms that are increasingly governing our world. While APIs can't provide 100% visibility into what algorithms do or do not do, they can provide access to the inputs and the outputs of the algorithms, making them more observable. When you combine with modern approaches to API management, it can do this securely and in a way that considers any end-user, as well as developer and platform interests. I'm going to keep investing in fine-tuning my argument for APIs to be used as part of artificial intelligence, machine learning, and the other classifications of algorithms that are being put to use across most business sectors. It's a relatively new area of my API research, but something I will invest more time and resources into to help push the conversation forward. 

More API Storytelling Is Needed (and Is the Most Rewarding Part of What I Do)

I've done an OK job at instigating other API service providers, API operators, integrators, and individuals to tell their story. I feel that my biggest impact on the space has been producing the @APIStrat conference with my partner in crime Steve Willmott at 3Scale/Red Hat, which is focused on giving people across the API sector a diverse, inclusive place to tell their story on stage and in the hallways. Next, I'd say my regular storytelling on my blog, like my evergreen post on the secret to Amazon's success, has had the biggest impact, while also being the most rewarding and nourishing part for me personally. I've heard stories about my Amazon blog post being framed on the wall in a bank in Europe, baked into the home page of the IT portal for government agencies, and many other scenarios. Stories matter. We need more of it. I am optimistic regarding much of the new writing I'm seeing on Medium, but this storytelling being mostly isolated to Medium worries me.

Keep On Keepin' On With API Evangelist the Best I Can

I still believe in APIs. Over the last seven years, my belief in what APIs can do has not diminished. My belief in what people are capable of doing with them has tremendously. I enjoy staying in tune with what is going on and trying to distil it down into something people can use in their own API operations. I think the biggest areas of concern for the API life cycle in coming years will be in the areas of API definitions, security, terms of services, privacy, discovery, intellectual property, and venture capital

I just needed to refresh my argument of why I still believe in APIs. Honestly, 2015 and 2016 really stretched my faith when it came to APIs. Once I realized it was primarily a crisis of faith in humans and not in APIs, I was able to find a path forward again with API Evangelist. Really, I couldn't ask for a better career focus. It keeps me reading, learning, and thinking deeply about something that touches all of us, and possesses some really meaningful areas that could make an actual impact on people's lives. Things like Open Referral, my work on FAFSA, EPA, National Park, Census, Energy, API Commons, and APIs.json keep me feeling that APIs can make a positive impact on how our world works.

In 2017, I don't think I need to spend much time convincing people to do APIs. They are already doing this. There is more going on than I can keep track of. I think I need to focus on convincing people to do APIs as open and observable as they possibly can. Push for a balanced approach to not just the technology but the business and legal side of platform operations in a way that protects the platform's operations, in a way that is looking out for the third-party developer and end-user interests. I still believe in APIs, but only if they possess the right balance, which I talk about regularly; otherwise, they are just another approach to technology that we are letting run amok in our lives.

Discover the six challenges and best practices in managing microservice performance, brought to you in partnership with AppDynamics.

Topics:
apis ,integration ,applications

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

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

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

X

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

{{ parent.tldr }}

{{ parent.urlSource.name }}