Let's Not REST ...Sometimes

Representational State Transfer (REST) is a framework that was developed in 2000 to enable services to communicate over the Internet. REST is a way of designing a system and an API. It’s designed to work independently of the transport protocol, but is certainly most commonly used over HTTP for web services on the Internet. 

REST is now ubiquitous for web services. It’s essentially the go-to mechanism for any new web service. Most web development frameworks support a REST module that can be used off the shelf. It has many useful features when used with web services. It provides predictable urls and operations. Usually, it also provides predictable responses to operations. If you’re developing backend systems, the use of REST allows you to get from zero to prototype very quickly. 

A number of REST limitations were documented, for example, here, here and here. But I'll discuss my personal experience with REST limitations in this article.

Back in 2008 we were developing our first production release of our online health portfolio service (don’t be fooled by the simple look of the site, it has a highly sophisticated backend!). We considered a REST approach. However, we came across a number of questions that we couldn’t answer easily with REST. We had complex and dynamic data filtering requirements that often involved traversing several objects. Often, a number of objects needed to be displayed on the same screen and bandwidth and speed were an issue for our mobile apps. Also, we needed to express complex and dynamic filters in client requests, which was almost impossible to do with current REST frameworks, which are typically limited to expressing filters in the URL.

We found that these requirements, among others, made the use of REST “chatty” and wasteful when considering bandwidth and speed. Needless to mention, bandwidth and speed have a direct impact on the user experience, especially in a mobile environment. Furthermore, from an engineering point of view, the whole approach seemed wasteful for our use case. 

We decided to build our own approach, which wasn’t made generic enough to release as open source at the time. Unfortunately, in a startup, cost-savings come before generalisations for the open source community.

Whenever I discussed these issues in the past with software engineers, I found resistance to go against the mainstream. The word “controversial” was often mentioned in their response. Luckily, Facebook obviously saw similar issues with mainstream REST implementations and built GraphQL; a very flexible framework that can meet the modern requirements of web and mobile services. It certainly addresses most of the issues we faced in our product development of web-based RESTful API's.

Now, if you read this far, you might conclude that none of the issues I mentioned above are REST-specific, they're more about REST frameworks and their own implementation choices and limitations. GraphQL is also REST isn't it? That's true to a large extent, I've intentionally conflated the REST implementations available today with the more academic definition of REST because that's the reality of current implementations, which are essentially the pseudo-standard for REST. Also, it's a good way of getting your attention to the issues.

So what's the answer? Should we not use REST? I think the answer is to consider your applications and requirements very carefully. Don't accept pseudo facts and don't go blindly with the flow. Objectively assess your requirements and at least be aware of the limitations of any framework you use so you can build a migration path and avoid nasty surprises. In many cases, an off-the-shelf REST framework will do a great job. In other cases it won't work for you. I think GraphQL, or something like it (or better) is probably a safer bet for the vast majority of cases.