HTTP Methods Explained
What HTTP Methods Are and Why They Matter
HTTP methods are verbs that state the action a client wants to perform on a resource. Every request includes one method, and the server uses it together with the URL to decide what to do. The same address can be read, replaced or removed depending on the method sent to it. For how methods fit into a full exchange, see what an API call is.
Methods make APIs predictable. A developer who sees GET on a customer endpoint expects to receive data, not change it. Caches and monitoring tools also rely on the method to decide how to handle a request, so choosing the right method matters even when another method would technically work.
The Five Common Methods and What Each One Does
- GET retrieves a resource or a list of resources. It should not change anything on the server.
- POST creates a new resource or starts a process, such as placing an order. The server often assigns the new resource's address and returns it in the response.
- PUT replaces a resource with the complete version sent in the body. Fields left out are typically cleared.
- PATCH changes only the fields included in the body and leaves the rest alone.
- DELETE removes a resource.
The difference between PUT and PATCH is how much data the request carries. PUT means this is the complete new version, while PATCH means change only these fields. Sending less data with PATCH also reduces the risk of overwriting fields the client did not mean to touch.
These methods map to the four basic data operations, often called CRUD: create, read, update and delete. POST creates, GET reads, PUT and PATCH update, and DELETE removes. Many REST APIs are built on this mapping; see what a REST API is.
Safe and Unsafe Methods
A method is safe when it is meant to be read-only. GET and HEAD, which returns only headers, are the standard safe methods. Clients and caches can repeat safe requests without changing the resource.
POST, PUT, PATCH and DELETE are unsafe because they change data. Unsafe methods need more care. A repeated POST might create two orders, and a retried request might produce effects the client did not intend. Whether a repeated request has the same effect as the first is called idempotency, which has its own article: what idempotency means in APIs.
Frequently asked questions
What is the difference between PUT and PATCH?
PUT replaces the whole resource with the data in the request body, while PATCH applies a partial change to only the fields it sends. Use PUT when the client holds the complete updated record, and PATCH when it needs to change one or two fields. The exact format of a PATCH body is defined by each API's documentation.
Is it acceptable to send data in a GET request?
Generally no. GET requests are meant to retrieve data, so they should not change anything on the server. Data sent in a GET request appears in the URL, where it can be stored in server logs and browser history. Use POST, PUT or PATCH, which carry the data in the body, when sending information that changes a resource or is sensitive.