REST in Peace. Long Live GraphQL

by Kai Wedekind

If you have worked with REST API’s then you know that they are fairly rigid. API Endpoints are either all or nothing; you don’t get the chance to pick and choose what you want. You get your entire array, or object, back even if you only need a few pieces of their data.

A REST API has a rigid definition that must be followed. Typically you would make separate HTTP requests to retrieve the data you need. This can sometimes take multiple HTTP requests which can make your application very network intensive, negatively affecting performance. Finally, once the client has received the data from the requests, it can often take a lot of work to format it for the needs of your application.

Typically, your data will change over time, and you’ll need to introduce new versions of your API while maintaining older versions as well. This is necessary because some users continue to rely on older versions of your API. where those new data changes have not yet been implemented. REST can get messy very quickly as the endpoints grow, and as a result is tricky to debug. You can think of it like the quote from Henry Ford in 1909:

You can have it in any color as long as it’s black

Here’s a quick example to illustrate the rigidity of REST APIs. Each data type needed requires a specific API endpoint, ultimately forcing you to make multiple HTTP requests.

GET /repos/:owner/:repo/issues/:number/comments