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

Question

Apparently  REST is just a set of conventions about how to use HTTP  I wonder which advantage these conventions provide  Does anyone know

User · Answer

Discovery is far easier in REST  We have WADL documents  similar to WSDL in traditional webservices  that will help you to advertise your service to the world  You can use UDDI discoveries as well  With traditional HTTP POST and GET people may not know your message request and response schemas to call you

User · Answer

It s written down in the Fielding dissertation  But if you don t want to read a lot    increased scalability  due to stateless  cache and layered system constraints  decoupled client and server  due to stateless and uniform interface constraints   reusable clients  client can use general REST browsers and RDF semantics to decide which link to follow and how to display the results  non breaking clients  clients break only by application specific semantics changes  because they use the semantics instead of some API specific knowledge

User · Answer

Timmmm  about your edit    GET  timeline posts        could return the N first posts  with links to fetch the next previous N posts   This would dramatically reduce the number of calls  And nothing prevents you from designing a server that accepts HTTP parameters to denote the field values your clients may want     But this is a detail   Much more important is the fact that you did not mention huge advantages of the REST architectural style  much better scalability  due to server statelessness  much better availability  due to server statelessness also  much better use of the standard services  such as caching for instance  when using a REST architectural style  much lower coupling between client and server  due to the use of a uniform interface  etc  etc    As for your remark       Not all actions easily map to CRUD  create  read retrieve  update    delete        an RDBMS uses a CRUD approach  too  SELECT INSERT DELETE UPDATE   and there is always a way to represent and act upon a data model   Regarding your sentence       You may not even be dealing with object type resources      a RESTful design is  by essence  a simple design - but this does NOT mean that designing it is simple  Do you see the difference   You ll have to think a lot about the concepts your application will represent and handle  what must be done by it  if you prefer  in order to represent this by means of resources  But if you do so  you will end up with a more simple and efficient design

User · Answer

Give every    resource    an ID Link things together Use standard methods Resources with multiple representations Communicate statelessly   It is possible to do everything just with POST and GET  Yes  is it the best approach  No  why  because we have standards methods  If you think again  it would be possible to do everything using just GET   so why should we even bother do use POST  Because of the standards   For example  today thinking about a MVC model  you can limit your application to respond just to specific kinds of verbs like POST  GET  PUT and DELETE  Even if under the hood everything is emulated to POST and GET  don t make sense to have different verbs for different actions

User · Answer

Simply put  NONE   Feel free to downvote  but I still think there are no real benefits over non-REST HTTP  All current answers are invalid  Arguments from the currently most voted answer    Simple  You can make good use of HTTP cache and proxy server to help you handle high load  It helps you organize even a very complex application into simple resources  It makes it easy for new clients to use your application  even if you haven t designed it specifically for them  probably  because they weren t around when you created your app     1  Simple  With REST you need additional communication layer for your server-side and client-side scripts    it s actually more complicated than use of non-REST HTTP   2  Caching  Caching can be controlled by HTTP headers sent by server  REST does not add any features missing in non-REST   3  Organization  REST does not help you organize things  It forces you to use API supported by server-side library you are using  You can organize your application the same way  or better  when you are using non-REST approach  E g  see Model-View-Controller or MVC routing   4  Easy to use implement  Not true at all  It all depends on how well you organize and document your application  REST will not magically make your application better

User · Answer

Caching   There are other more in depth benefits of REST which revolve around evolve-ability via loose coupling and hypertext  but caching mechanisms are the main reason you should care about RESTful HTTP

User · Answer

Query-strings can be ignored by search engines

User · Answer

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    Your web API may be cleaner and easier to understand   discover  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    Not all actions easily map to CRUD  create  read retrieve  update  delete   You may not even be dealing with object type resources  It s extra effort for dubious benefits  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

User · Answer

One advantage is that  we can non-sequentially process XML documents and unmarshal XML data from different sources like InputStream object  a URL  a DOM node

User · Answer

Simply put  REST means using HTTP the way it s meant to be   Have a look at Roy Fielding s dissertation about REST  I think that every person that is doing web development should read it   As a note  Roy Fielding is one of the key drivers behind the HTTP protocol  as well   To name some of the advandages    Simple  You can make good use of HTTP cache and proxy server to help you handle high load  It helps you organize even a very complex application into simple resources  It makes it easy for new clients to use your application  even if you haven t designed it specifically for them  probably  because they weren t around when you created your app

User · Answer

I recommend taking a look at Ryan Tomayko s How I Explained REST to My Wife  Third party edit  Excerpt from the waybackmaschine link   How about an example  You   re a teacher and want to manage students     what classes they   re in   what grades they   re getting   emergency contacts   information about the books you teach out of  etc     If the systems are web-based  then there   s probably a URL for each of the nouns involved here  student  teacher  class  book  room  etc      If there were a machine readable representation for each URL  then it would be trivial to latch new tools onto the system because all of that information would be consumable in a standard way      you could build a country-wide system that was able to talk to each of the individual school systems to collect testing scores    Each of the systems would get information from each other using a simple HTTP GET  If one system needs to add something to another system  it would use an HTTP POST  If a system wants to update something in another system  it uses an HTTP PUT  The only thing left to figure out is what the data should look like

User · Answer

IMHO the biggest advantage that REST enables is that of reducing client server coupling   It is much easier to evolve a REST interface over time without breaking existing clients

User · Answer

Discoverability  Each resource has references to other resources  either in hierarchy or links  so it s easy to browse around  This is an advantage to the human developing the client  saving he she from constantly consulting the docs  and offering suggestions  It also means the server can change resource names unilaterally  as long as the client software doesn t hardcode the URLs    Compatibility with other tools  You can CURL your way into any part of the API or use the web browser to navigate resources  Makes debugging and testing integration much easier   Standardized Verb Names  Allows you to specify actions without having to hunt the correct wording  Imagine if OOP getters and setters weren t standardized  and some people used retrieve and define instead  You would have to memorize the correct verb for each individual access point  Knowing there s only a handful of verbs available counters that problem   Standardized Status  If you GET a resource that doesn t exist  you can be sure to get a 404 error in a RESTful API  Contrast it with a non-RESTful API  which may return  error   Not found   wrapped in God knows how many layers  If you need the extra space to write a message to the developer on the other side  you can always use the body of the response   Example  Imagine two APIs with the same functionality  one following REST and the other not  Now imagine the following clients for those APIs   RESTful   GET  products 1052 reviews POST  products 1052 reviews        5 stars  DELETE  products 1052 reviews 10 GET  products 1052 reviews 10   HTTP   GET  reviews product id 1052 POST  post review product id 1052                   5 stars  POST  remove review product id 1052 amp review id 10 GET  reviews product id 1052 amp review 10   Now think of the following questions    If the first call of each client worked  how sure can you be the rest will work too  There was a major update to the API that may or may not have changed those access points  How much of the docs will you have to re-read  Can you predict the return of the last query  You have to edit the review posted  before deleting it   Can you do so without checking the docs

User · Answer

I would suggest everybody  who is looking for an answer to this question  go through this  slideshow     I couldn t understand what REST is and why it is so cool  its pros and cons  differences from SOAP - but this slideshow was so brilliant and easy to understand  so it is much more clear to me now  than before

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

Examples related to rest