The Disadvantages of REST Are Its Advantages

I was recently asked a very interesting question as part of an interview process: "what are the disadvantages of REST?" I could think of a few issues off the top of my head, but they turned out to be deeper than I'd thought, and I had to research them.

It turns out what's just as interesting as the issues is that REST is questioned at all--not as much discussion as you might think has been posted to the blogosphere. I found the following discussed in various articles. In each case, I came to the conclusion that the main disadvantages of REST are also its advantages.

REST is stateless

While statelessness is usually an advantage for CRUD operations, it's not suitable for some scenarios. An app makes discrete requests to a service using a REST API, but it's disconnected--the service is unaware of the app's state and vice versa. Therefore, REST is not ideal for continuing operations for which the service needs context about the state of the client app.

For example, consider a web service that allows you to query prices of commodity shares using GET requests and to make purchases using POST requests. The market share price changes continually, and could differ significantly between requests. The web service would have to implement additional application logic to ensure the client can purchase shares at the desired price.

REST has no built-in security

REST relies on TLS/SSL for secure data transaction, but authentication is not part of REST. REST does not have built-in security, so developers need to implement their own mechanism. Here are the usual methods:

• Basic authentication (username and password) in the client app; this can be augmented with 2FA
• OAuth1 (uses a cryptographic signature)
• OAuth2 (no cryptographic signature)
• Custom protocols (e.g. some web services provide unique API keys to app developers)

This article has deeper information on the above security methods: Secure Your REST API the Right Way.

REST has too few verbs

It's been suggested that REST needs additional verbs (such as MERGE, INCLUDE, or APPEND). In my opinion, this isn't a real drawback; most web services only use the 4-5 most common verbs, and PATCH covers other cases. It seems to me the real problem is that POST tends to be overloaded and has become a catch-all for most processing operations.

REST depends on HTTP

This is mostly an advantage, but has disadvantages. Using HTTP as the app transport protocol makes REST available on any app or browser with an HTTP connection. In cases where HTTP is not available, REST can't operate. In contrast, SOAP can use virtually any transport.

The above points aren't an exhaustive list, and the InfoQ article What Are the Drawbacks of REST? goes into further depth on the subject. This article provided me a great deal of guidance and insight for this post.