The title alone may startle non-technical readers, but we’ll try to keep this as straightforward as possible. In today’s article, Software Planet Group are taking a look at application programming interfaces (or APIs), which have often been described as an agreement between developers on how devices and applications should be exchanging data with their parent servers.
At least for now, your company’s best bet will more than likely be GraphQL or REST. So let’s quickly take a look at them:
What is REST?
REST, or representational state transfer, is a software communication architecture pattern which revolves around the idea of the resource. Every resource — which may be anything from users, authors or articles — is identified by a separate URL, and can then be fetched by sending out an unambiguous GET request. Unlike other APIs, REST provides no special tooling or libraries. It is merely a set of instructions on how to access all the data you need.
Nonetheless, this by no means means that REST is short in the merit department. Especially over HTTP2, for instance, it provides exceptionally high performance, is able to scale indefinitely and works with server-driven application states (the server lets you know exactly what you can call and when).
Yet though REST may have proven itself for decades, more recently, a strong contender has emerged to give the protocol a run for its money.
What is GraphQL?
Developed by Facebook back in 2012, GraphQL, by contrast, is an open source query language. Its most obvious distinguishing feature is the so-called GraphQL schema, which provides a central location where all the data is effectively described. Though initially, the way in which you fetch resources is in fact fairly similar to REST, the obvious difference here is where developers can go from there.
For instance, while GraphQL delivers additional data by following relationships defined in the schema, in REST this is impossible unless the programmer sends out multiple requests. Not only does this give clients much more control over the information being sent, but data fetching can also be entirely UI-driven.
Take AirBnb’s search page as an example. Here, you will frequently see results for houses, flats, adventures, and other related experiences. In order to do this with a single request, AirBnb make use of a GraphQL query that is instructed to select only UI-specific information. This creates an ingenious separation of concerns, as the client handles requirements while the server is left to deal with the data structure. As a result, GraphQL is able to make data transfers significantly more efficient.
What are the drawbacks of REST?
But of course, not everything is sunshine and rainbows. Especially when different vendors are responsible for your app’s frontend and backend, the REST protocol may indeed be prone to a number of unexpected surprises. One commonly cited issue is that because REST is so reliant on endpoints, frontend developers are often forced to wait for their backend counterparts to do their jobs. This causes unnecessary delays and an unwarranted degree of frustration. By contrast, with GraphQL, you can always access the data you need without specifying it all beforehand.
Furthermore, REST’s aforementioned lack of tooling calls for discipline from all parties involved.
What are the drawbacks of GraphQL?
As for GraphQL, though it is undeniably more flexible than REST, the added flexibility will also come at a perceptible cost. If, for instance, an ill-intentioned individual were to gain access to your client-side code, they would be able to structure malevolent requests that could potentially overload your system. Consider a massive report requesting data from the previous 10 years. Put mildly, your servers would seriously struggle to cope! Of course, with appropriate security, this danger may also be substantially curbed.
GraphQL may also not be ideal when dealing with microservices, as it does not currently possess the ability to return data from multiple services. This, by contrast, can be accomplished rather easily with REST.
Moreover, GraphQL sometimes leads to bikeshedding, as too much time is spent on largely tangential matters like network errors, content negotiation and caching.
If you’ve made it this far, congratulations! You now have a solid understanding of two incredible available APIs. So which to pick for your next software project? Well, as always, there is never really a silver bullet, as this will inevitably depend on a variety of different factors.
In general, however, those who are committed to following REST API’s best practices will probably be convinced that GraphQL falls a little flat. On the other hand, if you are looking for the very latest in API technology, with a client-centric protocol that is trusted by major brands, then Facebook’s GraphQL query language will all but certainly serve you well.
Whatever your final decision, of course, SPG have got you more than covered!