HTTP Methods: GET, POST, PUT, PATCH, DELETE Compared (Safe and Idempotent)

An HTTP method tells the server what the client wants to do with a resource. Two properties matter when you design or retry requests. A safe method does not change server state, so it is harmless to repeat. An idempotent method has the same effect whether you send it once or many times.

Method	Safe	Idempotent	What it does	Defined in
`GET`	Yes	Yes	Retrieve a representation of a resource. It should not change anything on the server.	RFC9110, Section 9.3.1
`HEAD`	Yes	Yes	Same as GET but returns only the headers, useful to check a resource without downloading it.	RFC9110, Section 9.3.2
`POST`	No	No	Submit data to be processed, often creating a resource or triggering an action.	RFC9110, Section 9.3.3
`PUT`	No	Yes	Replace the target resource with the request body, or create it at that URL.	RFC9110, Section 9.3.4
`PATCH`	No	No	Apply a partial modification to a resource.	RFC5789, Section 2
`DELETE`	No	Yes	Remove the target resource.	RFC9110, Section 9.3.5
`OPTIONS`	Yes	Yes	Ask which methods and options a resource supports. Browsers use it for CORS preflight.	RFC9110, Section 9.3.7
`CONNECT`	No	No	Open a tunnel to the destination, mostly used by proxies for HTTPS.	RFC9110, Section 9.3.6
`TRACE`	Yes	Yes	Echo the request back for diagnostics. Often disabled for security.	RFC9110, Section 9.3.8

PUT, POST or PATCH?

PUT replaces the whole resource at a known URL. Sending it twice leaves the same result, which is why it is idempotent.
POST sends data for the server to process, often creating a new resource at a URL the server chooses. Repeating it can create duplicates.
PATCH changes part of a resource. It is not required to be idempotent, since it depends on how the patch is defined.

Why it matters

Clients, proxies and browsers may automatically retry idempotent requests after a network failure but should not blindly retry POST. For the codes servers answer with, see HTTP status codes.