Menu
Why should I use REST if I can get my job done with only post and get requests?
421
In addition to using HTTP for simplicity, REST offers a number of other benefits over SOAP: REST allows a greater variety of data formats, whereas SOAP only allows XML. Coupled with JSON (which typically works better with data and offers faster parsing), REST is generally considered easier to work with.
One of the key advantages of REST APIs is that they provide a great deal of flexibility. Data is not tied to resources or methods, so REST can handle multiple types of calls, return different data formats and even change structurally with the correct implementation of hypermedia.
REST aims to make caching easier. Since the server is stateless and each request can be processed individually, GET requests should usually return the same response regardless of previous ones and the session. This makes the GET requests easily cacheable and browsers usually treat them as such.
Roy Fielding blogged with some frustration about RPCs masquerading as REST.
REST demands the use of hypertext, which scales very well since the client and server are very loosely coupled. With REST, the server is free to change the exposed resources at will. There is no fixed API above and beyond what REST itself defines. The client needs only know the initial URI, and subsequently chooses from server-supplied choices to navigate or perform actions. A server may download code to the client which aids in navigation and state representation.
All of this is in stark contrast with the various remote procedure call (RPC) schemes in which the client and server must agree upon a detailed protocol that typically needs to be compiled into both ends (e.g. URIs of a particular form accessed in a particular order at one extreme, SOAP/WSDL/WS* at the other). This approach is brittle, because any changes need to implemented on both the server and client sides at the same time. It rapidly becomes untenable as the number of servers and/or clients grows. Servers in particular suffer because evolution of the published API becomes progressively more difficult as popularity increases.
In light of these factors, REST is always the better choice when possible. It allows for rapid evolution of servers and allows an astronomical number of applications to interact freely on an ad hoc basis (e.g. the whole Internet).
But what about the "when possible" part? REST works best when there is a human in the loop. After all, a human has a good chance of being able to make a rational choice when presented with a previously unknown set of options. Machines aren't there yet. Web RPC protocols were born precisely to handcuff both sides to a fixed protocol. This makes it easier for automated processes to communicate when the human is removed from the picture. An RPC is a valid design choice when purely automated operation is more important than evolution and scalability (in Internet time and on an Internet scale).
Scale and Coupling?
"Scale" here is meant in a broad sense. It includes numbers of users and sessions, yes, but also application size and development process. Tight coupling presents a severe impediment to application size. It is hard to imagine the existence of the largest known application, the World-Wide Web, without the extremely loose coupling afforded by the REST architecture. Millions of developers around the globe have collaborated to build this application that supports billions of users. Yet the developers do this while remaining blissfully unaware of each other (or at least they would be unaware of each other if it weren't for StackOverflow ;).
The primary enabling principle of REST is hypertext. The other elements of the architecture exist to support that principle in very large scale (in every sense). Is REST the only conceivable way that the Web could have been built? No. But it happens to be the wildly successful de facto standard. It should be the default choice for any new entry into the ecosystem, discarded only after careful and explicit design consideration.
100
Using REST correctly can help your system components remain properly decoupled and can be evolved more easily in the future than if you had tied them directly together in a typical RPC-like fashion. It's an architectural choice that you must make based on your application's needs. Others have noted some of the technical benefits, and they should be taken into account too.
43
REST allows easy evolution of an API design. And that's the key with REST - you're creating an API. Some of the comments have touched on aspects of this thought, but have not actually brought the core issue to life. When you are dealing with REST, you are creating an API that would be used by clients (or yourself). The HTTP actions on the resources give a clear indication to the clients of the API design and functionality. Therefore, when we use the correct HTTP verbs properly, we are declaring an API that is standardised and understandable from a client perspective.
20
If your GET requests are not idempotent then HTTP caching between your server and clients would break your application. POST requests are by definition not idempotent, so HTTP caches will not cache these requests and results: you still get the benefits of caching GET requests, without breaking your application's protocol. Great success.
And, if you ever need to delete objects, DELETE will be much easier to read on the wire and logs than a POST request that does the deletion. But web browsers cannot easily make HTTP requests with the DELETE verb, so it's really more for clients you've programmed yourself.
34
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
