Skip to main content

4.5. Using HTTP Methods

4.5. Using HTTP Methods​

Applications that use HTTP MUST conform to the semantics of the methods they use, as defined in [HTTP]. They MAY define new methods, but if they do so, they MUST register them following the procedure in [HTTP] Section 16.1.

New methods are rare; they are only necessary when no existing method's semantics allow what is needed. Usually, it's sufficient to define a new Content-Type for request bodies and/or a Link relation in responses to disambiguate semantics.

For example, if an application wants to define an operation to "relocate" a resource, it would be inappropriate to define a new RELOCATE method because PUT can already be used to change the state of a resource (by providing a new representation containing the updated location).

When specifying the use of methods, it's important to consider the various properties they have, such as safety, idempotence, and cacheability.

Applications SHOULD use existing HTTP methods where possible. In particular:

  • GET SHOULD be used for operations that are safe and cacheable (as per [HTTP] Sections 9.2.1 and 15.4).

  • HEAD SHOULD be supported wherever GET is.

  • POST SHOULD be used for operations that are neither safe nor idempotent.

  • PUT SHOULD be used for operations that store the enclosed representation under the supplied URL, replacing any existing representation.

  • DELETE SHOULD be used for operations that remove the resource identified by the URL.

See Section 4.5.1 and Section 4.5.2 for additional considerations when using GET and OPTIONS.

Last updated on