What is the advantage of using REST instead of non-REST HTTP?

by

I don’t think you will get a good answer to this, partly because nobody really agrees on what REST is. The wikipedia page is heavy on buzzwords and light on explanation. The discussion page is worth a skim just to see how much people disagree on this. As far as I can tell however, REST means this:

Instead of having randomly named setter and getter URLs and using GET for all the getters and POST for all the setters, we try to have the URLs identify resources, and then use the HTTP actions GET, POST, PUT and DELETE to do stuff to them. So instead of

GET /get_article?id=1
POST /delete_article   id=1

You would do

GET /articles/1/
DELETE /articles/1/

And then POST and PUT correspond to “create” and “update” operations (but nobody agrees which way round).

I think the caching arguments are wrong, because query strings are generally cached, and besides you don’t really need to use them. For example django makes something like this very easy, and I wouldn’t say it was REST:

GET /get_article/1/
POST /delete_article/     id=1

Or even just include the verb in the URL:

GET /read/article/1/
POST /delete/article/1/
POST /update/article/1/
POST /create/article/

In that case GET means something without side-effects, and POST means something that changes data on the server. I think this is perhaps a bit clearer and easier, especially as you can avoid the whole PUT-vs-POST thing. Plus you can add more verbs if you want to, so you aren’t artificially bound to what HTTP offers. For example:

POST /hide/article/1/
POST /show/article/1/

(Or whatever, it’s hard to think of examples until they happen!)

So in conclusion, there are only two advantages I can see:

  1. Your web API may be cleaner and easier to understand / discover.
  2. When synchronising data with a website, it is probably easier to use REST because you can just say synchronize("/articles/1/") or whatever. This depends heavily on your code.

However I think there are some pretty big disadvantages:

  1. Not all actions easily map to CRUD (create, read/retrieve, update, delete). You may not even be dealing with object type resources.
  2. It’s extra effort for dubious benefits.
  3. Confusion as to which way round PUT and POST are. In English they mean similar things (“I’m going to put/post a notice on the wall.”).

So in conclusion I would say: unless you really want to go to the extra effort, or if your service maps really well to CRUD operations, save REST for the second version of your API.

I just came across another problem with REST: It’s not easy to do more than one thing in one request or specify which parts of a compound object you want to get. This is especially important on mobile where round-trip-time can be significant and connections are unreliable. For example, suppose you are getting posts on a facebook timeline. The “pure” REST way would be something like 

GET /timeline_posts     // Returns a list of post IDs.
GET /timeline_posts/1/  // Returns a list of message IDs in the post.
GET /timeline_posts/2/
GET /timeline_posts/3/
GET /message/10/
GET /message/11/
....

Which is kind of ridiculous. Facebook’s API is pretty great IMO, so let’s see what they do:

By default, most object properties are returned when you make a query.
You can choose the fields (or connections) you want returned with the
“fields” query parameter. For example, this URL will only return the
id, name, and picture of Ben:
https://graph.facebook.com/bgolub?fields=id,name,picture

I have no idea how you’d do something like that with REST, and if you did whether it would still count as REST. I would certainly ignore anyone who tries to tell you that you shouldn’t do that though (especially if the reason is “because it isn’t REST”)!

More Related Contents:

  1. 400 BAD request HTTP error code meaning?
  2. SOAP vs REST (differences)
  3. How to design RESTful search/filtering? [closed]
  4. 400 vs 422 response to POST of data
  5. Pagination in a REST web application
  6. When do I use path params vs. query params in a RESTful API?
  7. How to create REST URLs without verbs?
  8. secure api data from calls out of the app
  9. S3 REST API and POST method
  10. REST Content-Type: Should it be based on extension or Accept header?
  11. How to send a message successfully using the new Gmail REST API?
  12. Are there any naming convention guidelines for REST APIs? [closed]
  13. How to expose a RESTful Web Service using Meteor
  14. Rest Standard: Path parameters or Request parameters
  15. How to use object filter with softlayer rest api?
  16. Does Karate DSL Framework have the capability to pass a POST Request as a url encoded format?
  17. What’s the currently recommended way of performing partial updates with Web API?
  18. Difference between Swagger & HATEOAS
  19. Delete multiple records using REST
  20. Is That REST API Really RPC? Roy Fielding Seems to Think So
  21. What is the difference between a HTTP-Get and HTTP-POST and why is HTTP-POST weaker in terms of security
  22. How do I get the body of a web request that returned 400 Bad Request from Invoke-RestMethod
  23. HTTP PATCH support in browsers
  24. VSTS use API to set build parameters at queue time
  25. RESTful – What should a DELETE response body contain
  26. Can I change the headers of the HTTP request sent by the browser?
  27. The MAC signature found in the HTTP request ‘…’ is not the same as any computed signature
  28. Response status code for searches in REST APIs
  29. Hyphen, underscore, or camelCase as word delimiter in URIs?
  30. Status code when deleting a resource using HTTP DELETE for the second time

Leave a Comment