A key concept in a REST architecture is a mapping between behaviors and the implementation. The best known way to this is mapping HTTP methods to resource behaviors. The applicable HTTP methods are GET, PUT, POST, DELETE, and HEAD. I will not be discussing the TRACE and CONNECT methods in this post. GET, PUT and HEAD are idempotent methods, meaning the result of the method (state of the resource) will be the same regardless of when, where or how many times they are called on a particular resource. Idempotency allows among other things the caching of responses, increasing the efficiency of the application or system.
PUT sends an entire resource representation to the server or peer to create or update a resource. The resource representation must be sent in it’s entirety because the resource cannot be updated in parts or portions because of PUT’s idempotency.
POST is the second most popular HTTP method, POST is used frequently in AJAX calls, form submissions and anything else imaginable. POST is a processing directive for the resource referred to in the URI/URL to handle, as such, the server or peer may handle the POST in any they define. POST is often used to update a resource, create a resource, call another HTTP method that’s not supported by the client or trigger some other processing on the server/client.
HEAD is identical to GET except it does not return the resource, rather it returns the existence and size of the resource that would be returned by a GET request.
DELETE requests the deletion of the resource found at the URI/URL address.
The idempotency and cacheability of GET, HEAD, and PUT allow for robust, efficient, and scaleable systems. The immense power and flexibility POST allow enumerable systems and applications in every domain to live on the internet.