Why we should use REST?

Why should I use REST if I can get my job done with only post and get requests?

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.

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.

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.

Why do you think only using POST and GET means it's not REST?

The point to REST is that each "resource" has a resource identifier, a URI. Each URI potentially has GET, POST, PUT, DELETE.

• GET is read
• POST is update
• PUT is create
• DELETE is delete

If you're not doing some of those things -- like PUT is kind of rare and a potential security hole -- then you don't.

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.

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.

You should use REST because it really encompasses all the potential actions you want to do on a resource/object.

• GET - Retrieve a resource based on given conditions
• POST - create a resource
• PUT - update a resource with the given updated attributes
• DELETE - delete a resource

Another reason is that it is a standard that everyone can implement and use. To read up on why standardization is important, I would suggest reading this and this (it is rather funny, but really helps people grasp the concept of REST).

You should use REST because of below features and advantages:

> Features

1. Stateless client/server protocol: Each HTTP contains all the necessary information to run it, which means that neither the client nor the server need to remember any previous state to satisfy it. Be that as it may, some HTTP applications incorporate a cache memory. This configures what is known as the stateless client-cache-server protocol: it is possible to define some of the responses to specific HTTP requests as cachable, so the client can run the same response for identical requests in the future. However, the fact that the option exists doesn't mean it is the most recommended.
2. There are four very important data transactions in any REST system and HTTP specification: POST (create), GET (read and consult), PUT (edit) and DELETE.
3. Objects in REST are always manipulated from the URI. It is the URI and no other element that is the sole identifier of each resource in this REST system. The URI allows us to access the information in order to change or delete it, or for example to share its exact location with third parties.
4. Uniform interface: to transfer data, the REST system applies specific actions (POST, GET, PUT and DELETE) on the resources, provided they are identified with a URI. This makes it easier to obtain a uniform interface that systematizes the process with the information.
5. Layer system: hierarchical architecture between the components. Each layer has a functionality within the REST system.
6. Use of hypermedia: hypermedia is a term coined by Ted Nelson in 1965 and is an extension of the concept of hypertext. This concept, taken to web page development, is what allows the user to browse the set of objects through HTML links. In the case of a REST API, the concept of hypermedia explains the capacity of an app development interface to provide the client and the user with the adequate links to run specific actions on the data.

> Advantages

1. Separation between the client and the server: the REST protocol totally separates the user interface from the server and the data storage. This has some advantages when making developments. For example, it improves the portability of the interface to other types of platforms, it increases the scalability of the projects, and allows the different components of the developments to be evolved independently.
2. Visibility, reliability and scalability. The separation between client and server has one evident advantage, and that is that each development team can scale the product without too much problem. They can migrate to other servers or make all kinds of changes in the database, provided the data from each request is sent correctly. The separation makes it easier to have the front and the back on different servers, and this makes the apps more flexible to work with.
3. The REST API is always independent of the type of platform or languages: the REST API always adapts to the type of syntax or platforms being used, which gives considerable freedom when changing or testing new environments within the development. With a REST API you can have PHP, Java, Python or Node.js servers. The only thing is that it is indispensable that the responses to the requests should always take place in the language used for the information exchange, normally XML or JSON.

Source