The way HTTP was designed and the way it's used today are vastly different. As described in RFC 2616, HTTP 1.1 defines a protocol for accessing resources. There are several verbs (known as methods) clients can use to perform actions on these resources:
- GET - Retrieves information about a resource. The GET method was designed to only return information about a resource, not to make any changes. GET requests were designed to be idempotent meaning it should not change the resource in any way or have any side effects.
- PUT - Creates a new resource or changes an existing resource. The PUT method is a way for clients to delete and modify resources.
- DELETE - Deletes a resource. The DELETE method is a way for clients to request for the server to delete or destroy a resource.
- POST - Creates subordinate resource. The POST method is a request to create a related resource as a subordinate or child resource or another resource. This method was designed to be used for creating resources such as annotations, replies on forums or comments.
This same vision is not shared by the major Web browser vendors. Despite containing significant portions of the HTTP 1.1 standard, modern Web browsers only support the GET and POST methods. This severely limits the options Web developers have at their disposal when designing web applications. And, since GET and POST are the only methods available, any clear distinction or responsibilities between the two methods are often confused or ignored. Many web applications don't make any distinction at all; GET is used for non-idempotent actions and POST is only used for forms. This confusion of the idempotency of GET requests is a significant factor in CSRF vulnerabilities.
REST (Representational State Transfer) is another, closely related philosophy. REST over HTTP uses the same methods and shares HTTP's stateless design. All of the information required to perform a RESTful action is included in the client's request over HTTP.
Rails implements a RESTful design even through web browsers don't implement all of the methods. Rails creates URLs that emulate these methods. For example, if there is a post resource in a blog, the URL to create a new post resource is /posts/create and the URL to delete a post resource with the ID of 7 is /posts/delete/7.
The use of RESTful resources in Rails application is significant to security because it re-enforces the role of GET and POST requests in web applications. GET requests are idempotent in RESTful applications, and while abuse of this convention still modifies resources, it has educated web developers to the role of the request methods. All non-idempotent requests are handled by POST requests, which are much harder to forge and much easier to protect.