Looking To 2024, What Do APIs Look Like?
20 Sep 2017
I am spending two days this week with the Capital One DevExchange team outside of Washington DC, and they’ve provided me with a list of questions for one of our sessions, which they will be recording for internal use. To prepare, I wanted to work through my thoughts, and make sure each of these answers were on the tip of my tongue–here is one of those questions, along with my thoughts.
I’m not a big fan of predictions. It is a game that analysts and investors play to try and shape the world they want to see. I’m usually focused on shaping the world I want to see by understanding where we are, how we got here, and making incremental shifts in our behavior today. I tend to think that technology futurists are more about ignoring the past, and being in denial about today, than they are ever about what is happening in the future. However, with that said, let me share some thoughts about what I think the future will hold when it comes to doing APIs.
Mostly, by 2024 things will look much like they do today. Nothing moves as fast we think they will in the tech sector. I’ve done a lot of studying the history of predictions by technology blogs, and analysts firms over the last decade about what they thought 2017 would be like, and it is 98% bullshit. It was more about getting what they wanted in the year they made the prediction, than it was ever about the future. Technology always feels like it is moving faster than ever before but honestly, what has happened in the last decade that is really seismic? I’d say iPhone is the biggest, with mostly everything else being pretty incremental, and slow moving.
By 2024, we will still be struggling with technical debt. However, the debt limit ceiling will have been raised significantly. We won’t have decoupled the monolith, all while adding to it. The web will still be preferred approach to delivering APIs, although there will be numerous add-ons, and proprietary bastardizations surgically attached to it. REST APIs will be relic of the past, but web APIs will still be the preferred approach because it is simple, however there will be multiple speed API approaches reflecting what we are seeing from gRPC. Think about how different the web APIs are today, from the web APIs in 2010–there really isn’t that many changes. They still suck as bad as they did back then, with a few well designed ones available–just like there was in 2010.
There will be significant movements in the world of API definitions and schema. OpenAPI will have opened up a flood of competing specifications, as well as industry specific implementations using those formats. With the mainstream adoption of web APis, the need for common schema, dictionaries, and design patterns will increase. A significant portion of these API definitions will follow the web, reusing existing patterns, and evolving them in meaningful ways. The rest will be proprietary, complex, and not actually do many API providers much good, yet they will be used by popular APIs, so they will end up being baked into systems and applications. There will never be a single definition to rule them all, although we will see some strong media types emerge that encourage doing APIs in a powerful way at scale.
Much of the API sector will be deployed on the backs of cloud giants. The web landscape will be so volatile and un-secure, small business will not be able to operate without the assistance of platforms with the security expertise to defend our APIs. Cyberwarfare will be normalized, and corporations and state actors will routinely disrupt, infiltrate, and make doing business online near impossible. If you want to stay in business as an API provider you will have to pay a security tax to a cloud enforcer to ensure your services stay up. This will continue to give a unhealthy amount of power to large companies to dictate which types of APIs should be available, which new ideas get created, and shaping the overall notion of what is APIs–kind of the gilded age, after the wild west.
In 2024, algorithmic APIs will outpace strictly data or content APIs, with artificial intelligence, and machine learning dominating the landscape. This shift will mostly cause noise, disturbances, and fuel cyber(in)security, but there will be incremental evolution in these disciplines that actually deliver real business value. There will be enough value created from AI, ML, and algorithmic APIs to keep investment going, but most of it will be hype, over promised, and just confusing to users, continuing to give APIs a bad time. Luckily APIs will also be used to help make these black box algorithms more observable, accountable, and regulated, although may will still remain out of sight due to intellectual property, complexity, and other forms of technological theater.
Another aspect the API space that will continue to move front and center is event-driven architecture. As API move into the mainstream, much of the design thinking that goes into them will be heavily centered around business activities, and the events that matter to humans (and companies). We will see event sourcing, webhooks, and real-time technologies continue to evolve and grow, and become baked into our API approaches, much like REST design patterns are today. While it will continue to grow and evolve, the event landscape will be littered with technologies that confuse, complex, and go against much of what we’ve built over the years with simple API design approaches, but this won’t stop folks from thinking it is a good idea.
APIs in 2024 won’t be the shiny, API saved world we envision. It will still be pretty messy, and many will question whether we should be doing APIs in the first place, but doing business on the web will require moving data, and content around at scale, leveraging open and commercial algorithms to get things done. So APIs will persist, but not necessary thrive. They will be ubiquitous, and rarely exciting. Kind of like a gas station or convenience store. You will use them daily, they will be everywhere, but rarely will they bring inspiration as they have in the early days. One side effect of this will be that all government will be doing APis, but sadly it won’t bring the agility, and nimbleness we’ve all promised. It will usually just make things harder, and open public resources up for exploitation by commercial vendors who are offering the true solution for a fee in the parking lot.