How many HTTP verbs are there?

I count 9 HTTP request methods (aka verbs):

GET
HEAD
POST
PUT
DELETE
CONNECT
OPTIONS
TRACE
PATCH

The above from: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

Is that it? will this ever change?

Registry

The HTTP 1.1 spec defines an Hypertext Transfer Protocol (HTTP) Method Registry. As of 2017-01, shows 39 entries:

• ACL
• BASELINE-CONTROL
• BIND
• CHECKIN
• CHECKOUT
• CONNECT
• COPY
• DELETE
• GET
• HEAD
• LABEL
• LINK
• LOCK
• MERGE
• MKACTIVITY
• MKCALENDAR
• MKCOL
• MKREDIRECTREF
• MKWORKSPACE
• MOVE
• OPTIONS
• ORDERPATCH
• PATCH
• POST
• PRI
• PROPFIND
• PROPPATCH
• PUT
• REBIND
• REPORT
• SEARCH
• TRACE
• UNBIND
• UNCHECKOUT
• UNLINK
• UNLOCK
• UPDATE
• UPDATEREDIRECTREF
• VERSION-CONTROL

HTTP 1.0

HTTP 1.0 defined three methods (“verbs”):

• GET
  … retrieve whatever information … is identified by the Request-URI…
• POST
  … to request that the destination server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line… Posting a message to a bulletin board, newsgroup, mailing list … Providing a block of data … Extending a database through an append operation …
• HEAD
  … identical to GET except that the server MUST NOT return a message-body in the response … for obtaining metainformation about the entity implied by the request without transferring the entity-body itself…

HTTP 1.1

HTTP 1.1 is officially defined in RFC 2068. This spec added five more methods.

• OPTIONS
  …a request for information about the communication options available on the request/response chain… determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval
• PUT
  …requests that the enclosed entity be stored under the supplied Request-URI. If … already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server…
• DELETE
  …delete the resource identified by the Request-URI…
• TRACE
  …loop- back of the request message…
• CONNECT
  …for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling…

HTTP Extensions

Other protocols extend HTTP to define additional methods/verbs.

• PATCH
• Applies partial modifications to a resource
• Defined by RFC 5789
• WebDAV specifies seven more methods:
  • PROPFIND
  • PROPPATCH
  • MKCOL
  • COPY
  • MOVE
  • LOCK
  • UNLOCK

HTTP/2

HTTP/2 is defined in RFC 7540. Section 3.5 defines a PRI method.

• PRI
  In HTTP/2, each endpoint is required to send a connection preface as a final confirmation of the protocol in use and to establish the initial settings for the HTTP/2 connection. … the connection preface starts with the string "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n") …

Prognostication

will this ever change?

Not likely.

Given the wide use of Web RPC and SOAP, and now the rising popularity of RESTful services bringing new life to the existing basic verbs, there is little need to devise new verbs at the HTTP level. Where people need their own domain-specific meaningful verbs, they can embed within the message being delivered via HTTP.

I expect we’ll not see more HTTP methods become popular any time soon.

Custom Method (verb)

Be aware that you are allowed to invent you own custom methods.

To quote the HTTP/1.1 specification, section 9 Method Definitions:

The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed to share the same semantics for separately extended clients and servers.

So you can define your own methods. But, of course, you cannot expect that method to mean anything to just any server. You must ensure that both the client and the server are programmed to expect and comprehend your invented verb.

When you invent a custom method, be sure it is included in the response from OPTIONS.

Update circa 2022: QUERY

One new verb has been proposed, but seems to have died: QUERY. See The HTTP QUERY Method at the IETF.

To quote:

… a means of making a safe, idempotent request that contains content.

Most often, this is desirable when the data conveyed in a request is too voluminous to be encoded into the request's URI.