ReSTful APIs have been at the pinnacle of change for years. Heavily advocated by people like Jim Webber (what’s in a name?), APIs gained a lot of traction. They’re useful, so much has been proven. And they catch on. For instance, look at the list a guy named Todd Motto keeps. And this is just a small subset. Look at programmableweb.com for more. And even that is just a brief sliver of the total amount of APIs that are used inside and across organizations worldwide. It sure looks like the API is going the way of the website: without one, you don’t really exist.
At the same time, APIs are constrained and carry some weaknesses. Just like the early web, ReST APIs are passive in nature. The reply to a request, and that’s it. If you want to create a bidirectional interface, to update clients in real time, you’re possibly looking at WebSockets. Google is pushing GRPC as an alternative to ReST APIs, hailing HTTP/2 and strong typing with protobuf. O API has been suggested as an alternative. Facebook has GraphQL, which is great for doing a complex search. Netflix has Falcor, which ties the API model closely to the data model. And there are WebHooks, designed to bring JMS Topics to the programmable web.
WebHooks are a bit of a special case. There is no such thing as a WebHook specification, or a standards body that owns it. If anything, it’s a concept. WebSub, which we previously knew as PubSubHubbub, is an official protocol, adopted by the W3C, which takes the WebHooks concept into an official stage. Ballerina, the integration savvy, cloud native programming language, already supports WebSub.
So today we ask: have we reached the API peak already?
The ReST programming style has brought a huge improvement over the SOAP/WSDL/UDDI family of interoperability standards. It fully embraces the web and builds a distributed programming layer on top of it. It’s reasonably lightweight. If you understand URIs and encoding of HTTP requests, you’re good to go. But to truly benefit from the ReSTful programming paradigm, you have to understand HATEOS. That’s Hypertext As The Engine Of Application State. Every addressable unit of information carries an address, an URI to be specific.
Ever since distributed programming became a thing, architects have been discussing where to keep the state of interactions. If you keep it server-side, you run into limitations of scalability and consistency. You have to keep a connection to tie a state to a client. And clients on the internet are unreliable at best. However, when you keep state at the client, you risk loss of business. What if a user has just loaded his shopping cart, and the battery dies on him? Bad luck or bad design?
Similarly, handling paging is an issue. If a query result doesn’t fit into a single message, we’re used to browse through pages with the next and previous buttons, right? But one way or another, processing a “next” request requires information on the “current” state. The beauty of hypertext as the engine of application state is that state becomes an implicit part of the interface. It’s an identifier shared between the client and the server, and nothing more.
Although technically not part of ReST, we mostly see JSON messages inside the ReSTful HTTP bodies. Similar to XML Schema Definitions, JSON has its schema definition, which we can use to describe the message structure and for validation purposes. Since JSON has native support for tables, it does a better job than XML at representing business objects. Basically, you can describe any business object in JSON.
APIs enjoy an almost universal computer language support – both client-side and server-side. Additionally, there is a wealth of tools to design, publish, discover, test and control access to APIs. Hence your investment in APIs is very well justified.
The internet is still developing, and so are ReSTful APIs. We’ve HTTP/2 and Open API Specification 3. Both are big improvements. We fully expect more improvements in the future. But so far, we’re not convinced APIs are fundamentally flawed and anywhere near the verge of oblivion.
At Yenlo we strongly believe that APIs are very well suited to keep distributed systems manageable and secure. And because we’re Yenlo, we put our money where our mouth is. We’re betting on the future of APIs. That’s why WSO2 API Manager is at the center of Yenlo Connext. It’s the preferred point of entry and the single point of control.
With Yenlo Connext, we’re open minded. We want to offer the richest set of integration technologies in the market. So rest assured. If you have an integration challenge, Yenlo Connext has you covered. For any integration challenge. ReSTful, or otherwise. Now, and in the future. With today’s technologies and standards, and with future innovations. Zero hassle attached. Whatever it takes, we keep your information flow fluent.