RIP REST

2018 resolution: Say RIP to REST – aka “the year of RIP REST”

The specific resolution – only use “REST” casually, as a synonym for “client-server”

REST has had a pretty good run. The PhD dissertation was published in 2000. It did an awesome job describing the architecture of the web. Then some one, and then many ones, decided “the web” was a synonym for “enterprise network API”. That was a sad day, and the troubles began. Now, over a decade later, there is finally growing realization that “REST” is a terrible architecture for anything except web pages and maybe some key-value NoSQL APIs.

Section 5.1.5 “Uniform Interface” is one major failing.
Restricting a network architecture to the CRUD verbs is the opposite of “good network architecture”. This “Key-Value” design has been tried many times in the past. And rejected in almost every case. One domain where it stuck was “the web”. Another major failing in REST (although it is not in the dissertation) is the insistence on using HTTP response status codes at the REST level. This “mixing of levels” is another known anti-pattern (can you imagine writing your REST API using EBADF, EACCESS, EINVAL, etc.? Of course not, because the people who created HTTP understood protocol levels. But REST was attached at the hip to HTTP “for simplicity”).

It will be better days from now on – no more creating deficient network APIs in the name of REST. No more useless debates on versioning or HATEOS, or trying to “fix” REST. No more explaining “REST stands for REST Ein’t Soap, Tada!”. (Because that was all REST really was as a network API framework – REST was not SOAP.)

For those interested in what will replace REST, take a look at one possibility in GraphQL http://graphql.org/ GraphQL might not be the winner. But the winner will look a lot like it.