Some of the requests used in REST are as follows:
GET: TheGETrequest retrieves a representation of a resource from server to clientPOST: ThePOSTrequest is used to create a resource on the server based on the representation that the client sendsPUT: ThePUTrequest is used to update or create a reference to a resource on serverHEAD: TheHEADrequests checks for a resource without retrieving it
The next section will introduce the notion of safety and idempotence, two important terms associated with REST.
When it comes to REST, a safe method, by definition, is a HTTP method that does not modify the state of the resource on the server. For example, invoking a GET or a HEAD method on the resource URL should never change the resource on the server. PUT is considered not safe since it usually creates a resource on the server. DELETE is also considered not safe since it will delete the resource on the server. POST is not safe since it will change the resource on the server.
Idempotent method is a method that can be called multiple times yet the outcome will not change.
GET and HEAD are idempotent, which means that even though the same operation is done multiple times the result does not vary. PUT is idempotent; calling the PUT method multiple times will not change the result and the resource state is exactly the same.
DELETE is idempotent because once the resource is deleted it is gone, and calling the same operation multiple times will not change the outcome.
In contrast, POST is not idempotent and calling POST multiple times can have different outcomes.
Tip
The idempotence and safety of the HTTP verbs are a convention, meaning that when someone is using your API they will assume that GET/PUT/POST/DELETE have the same idempotency characteristics that are previously described; and the implementation of the business logic behind each verb should support these characteristics.
The response sent by the server could be in XML, JSON, or any other MIME type as long as the server supports the requested format. In case the server cannot support the requested MIME type, it can return with a status code of 406 (not acceptable).
When we are developing with RESTful principles in mind, each message should have enough information to let the server understand the purpose of the message and how to process that message, to produce the response the message is meant for, and finally to ensure visibility and statelessness.
Summarizing, these are the components of RESTful Web Services: