Interpretation on RESTful APIs
Okay, so recently I was reading some technical blogs and out of them all one topic really stick with me. So, I thought why not share my thoughts on that topic with you all. Well, the topic was about the future of RESTful APIs. Which later leaves me wondering that what will we see in new APIs whether they will be created on RESTful or graphql or something totally different.
Well, APIs are going to change some dynamics in the future and that’s invincible. But, how? So, this how leads us to the four different scenarios regarding the future of APIs.
#1. RESTful APIs Isn’t Full
Okay, so now this might shock you, but there isn’t any API or SPA present that solely works on REST. Yep, that’s because REST APIs lacks one of the important feature called “hypermedia”. Even the creator of REST, Roy Fielding, has shown his concerns regarding hypermedia in 2008.
“What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period. Is there some broken manual somewhere that needs to be fixed?”
Now, that was written way back a decade ago. But, lately, in 2013, Leonard Richardson, has said the same thing in the RESTful Web APIs book. And, the same concerns were shown in it. So, yeah, REST has done nothing much in the past ten years to improve the hypermedia of APIs.
#2. We Are Reinventing Wheel
By ignoring the standards of REST, we are making the life our developers and clients life hectic. Whereas Fielding and his team didn’t focus on the hypermedia, but Richardson has somehow accepted that the hypermedia is one of the single most important things that they are missing.
Richardson has also made a compelling case in the favor of hypermedia by giving an example that how we could save a lot of code and time on the server and on the client if we stopped inventing fiat standards for how collections work in our APIs.
With hypermedia, API developers don’t have to think that how to structure their JSON collection or about the structure of HTTP request needed to add a new item to the collection. Developers can use libraries which makes implementation of paging very easy.
#3. Why Are We Using Half REST?
So, why like the Chetan Bhagat’s Half Girlfriend, we are stuck with the half REST. Even after paying for RESTful services, why are we only using the half REST of APIs.
Well, the only answer to this question is a crappy internet connection. Still, after HTTP 2, the speed of the internet is very poor, especially in the mobile devices. And, this need for speed drives us towards the SPAs as there you won’t have to talk to server application state for every transaction. Even with the hypermedia, some JSON collaborations became bulky for the slow internet connection.
#4. GraphQL In 2018
Suppose if APIs are going to be developed in graphql and we totally ignore REST in 2018. Then, we don’t have to give up all the benefits of the REST, especially, the unrealized benefit of hypermedia and standardized Web API interfaces that saves the time of API designers, client programming designs, and coding.
Moreover, the future thinkers like Marc-André Giroux on Github have already thought about this and have a neat post on how we can include hypermedia-esque info in graphql mutation responses to inform the client which mutation it can perform next.
Well, as I have said earlier a post on the internet encouraged me to write this article. So, I could be totally wrong, that’s why don’t throw daggers at me as I have shared something cool with you. If you have any take on the topic, then you know you have to write it to us.