GET vs POST vs PUT vs PATCH
A practical guide to GET, POST, PUT, and PATCH HTTP methods, including when to use each method, how they differ, and how they work in REST APIs.
GET, POST, PUT, and PATCH are four of the most commonly used HTTP methods in web development. They appear in REST APIs, frontend applications, backend services, forms, integrations, and tools that communicate over HTTP.
The methods are not interchangeable. GET is primarily used to retrieve a resource, POST commonly creates a new resource or triggers an operation, PUT replaces a resource representation, and PATCH partially modifies a resource.
Understanding the differences matters because the HTTP method communicates the intended operation to the server. It also affects idempotency, caching, retries, API design, request bodies, and how clients should handle requests.
GET vs POST vs PUT vs PATCH at a Glance
| Method | Typical purpose | Request body | Idempotent | Safe |
|---|---|---|---|---|
| GET | Retrieve a resource | Usually no | Yes | Yes |
| POST | Create a resource or trigger an operation | Often yes | No | No |
| PUT | Replace or create a resource at a known URI | Usually yes | Yes | No |
| PATCH | Partially modify a resource | Usually yes | Can be | No |
The table describes common API usage rather than an absolute rule for every possible HTTP application. HTTP defines the semantics of the methods, while an individual API determines how its endpoints apply those semantics.
What Is an HTTP Method?
An HTTP method indicates the intended action for a request. A client sends a request to a server, and the method tells the server what kind of operation the client is asking it to perform.
GET /api/users/42 HTTP/1.1
Host: example.comIn this example, GET communicates that the client wants to retrieve the resource identified by the URL.
HTTP defines several methods, including GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, and others. GET, POST, PUT, and PATCH are especially common when building web APIs.
What Is GET?
GET requests are used to retrieve a representation of a resource. A GET request should not intentionally modify the resource on the server.
GET /api/products/123 HTTP/1.1
Host: example.com
Accept: application/jsonA successful response might contain the requested resource.
HTTP/1.1 200 OK
Content-Type: application/json
{
"id": 123,
"name": "Mechanical Keyboard",
"price": 99.99
}GET for Collections
GET is also commonly used to retrieve collections of resources.
GET /api/productsQuery parameters can be used for filtering, sorting, searching, or pagination.
GET /api/products?category=keyboards&sort=price&page=2These parameters are part of the request target. They are generally preferable to putting retrieval filters into a request body for a normal GET operation.
GET Is Safe
HTTP classifies GET as a safe method. Safe means that the client does not request a state-changing action as part of the method's intended semantics.
A server can still perform incidental work while processing a GET request, such as writing logs, updating metrics, or recording analytics. Safe does not mean that the server performs literally no internal work.
GET Is Idempotent
GET is idempotent. Repeating the same GET request should have the same intended effect on server state as making it once.
GET /api/users/42
GET /api/users/42
GET /api/users/42All three requests are intended to retrieve the same resource. This property makes GET suitable for many retry and caching scenarios.
What Is POST?
POST requests are commonly used to submit data to a resource for processing. In REST-style APIs, POST is frequently used to create a new resource in a collection.
POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json
{
"name": "Alex",
"email": "[email protected]"
}The server might create a new user and return the created resource.
HTTP/1.1 201 Created
Content-Type: application/json
{
"id": 501,
"name": "Alex",
"email": "[email protected]"
}POST Is Not Limited to Creation
POST is often associated with creating resources, but its semantics are broader. It can also be used when the client submits data for an operation that does not map cleanly to creating a resource.
POST /api/orders/501/checkoutAn API might use POST for operations such as checkout, starting a job, submitting a form, or triggering a server-side process. The exact endpoint semantics are defined by the API.
POST Is Usually Not Idempotent
POST is generally non-idempotent. Repeating the same request can produce multiple effects.
POST /api/orders
{
"productId": 123,
"quantity": 1
}If the first request creates an order, sending the same request again might create another order. This is why blindly retrying POST requests can be dangerous when the operation is not designed for duplicate submission.
What Is PUT?
PUT requests are commonly used to create or replace the representation of a resource at a known target URI. In REST APIs, PUT is often used when the client knows the resource's identifier.
PUT /api/users/42 HTTP/1.1
Host: example.com
Content-Type: application/json
{
"name": "Alex Smith",
"email": "[email protected]",
"role": "admin"
}A PUT request is commonly understood as replacing the current representation with the supplied representation. Exactly how missing fields are treated depends on the API contract, but clients should not assume that PUT behaves like a partial update.
PUT and Full Replacement
Consider a user resource with three fields: name, email, and role. A full PUT representation might include all three fields.
{
"name": "Alex Smith",
"email": "[email protected]",
"role": "admin"
}If the API defines PUT as replacement, sending a representation that omits role can have different consequences from PATCH. The API documentation should specify whether omitted properties are removed, reset, rejected, or otherwise handled.
PUT Is Idempotent
PUT is idempotent. If the same PUT request is successfully applied multiple times, the intended state after the first successful application should be equivalent to the state after subsequent identical applications.
PUT /api/users/42
{
"name": "Alex",
"email": "[email protected]"
}Sending that same request again should leave the resource in the same intended state rather than creating another user.
What Is PATCH?
PATCH is used to apply partial modifications to a resource. Instead of sending a complete replacement representation, the client can describe the changes it wants to make.
PATCH /api/users/42 HTTP/1.1
Host: example.com
Content-Type: application/json
{
"role": "editor"
}Here, the client is asking to modify the role without necessarily sending the other user properties.
PATCH Does Not Have One Universal Body Format
PATCH defines the concept of partial modification, but it does not require every API to use the same patch document format. APIs can define their own patch representation or use standardized formats such as JSON Patch or JSON Merge Patch.
{
"role": "editor"
}The example above is a common API-specific partial-update representation. It should not automatically be interpreted as JSON Patch. JSON Patch and JSON Merge Patch have their own media types and semantics.
Is PATCH Idempotent?
PATCH can be idempotent, but it is not inherently idempotent. The answer depends on the specific patch operation and how the server applies it.
For example, setting a user's role to editor is naturally idempotent: applying the same operation repeatedly results in the same role. An operation that increments a counter by one is not idempotent because repeating it produces another change.
| Operation | Repeated request |
|---|---|
| Set status to active | Idempotent in normal implementations |
| Set name to Alex | Idempotent |
| Increment balance by 10 | Not idempotent |
| Append an item to a list | Usually not idempotent |
PUT vs PATCH
The main distinction is replacement versus partial modification. PUT is generally used when the client sends the representation that should exist at the target URI. PATCH is intended for partial changes.
| Question | PUT | PATCH |
|---|---|---|
| Typical purpose | Replace a resource representation | Partially modify a resource |
| Usually sends | Complete representation | Only relevant changes |
| Idempotency | Yes | Can be idempotent |
| Known resource URI | Common | Common |
| Suitable for small field changes | Possible, but often verbose | Usually more natural |
POST vs PUT
POST and PUT are both commonly used with request bodies, but they communicate different semantics.
POST commonly submits data to a collection or endpoint for processing. The server often chooses the identifier of a newly created resource.
POST /api/users
{
"name": "Alex"
}PUT is commonly directed at a specific resource URI. The client therefore usually knows the target identifier.
PUT /api/users/501
{
"name": "Alex"
}The exact API design can vary, but this distinction is a useful REST convention.
GET vs POST
GET is intended for retrieval and is safe and idempotent. POST is intended for submitting data for processing and is generally neither safe nor idempotent.
| Aspect | GET | POST |
|---|---|---|
| Primary purpose | Retrieve | Submit/process |
| Changes server state | Not intended to | May change state |
| Request body | Usually not | Often |
| Idempotent | Yes | No |
| Safe | Yes | No |
| Common response | 200 OK | 201 Created or another appropriate status |
Request Bodies and HTTP Methods
A request body contains data sent with an HTTP request. POST, PUT, and PATCH commonly use request bodies when clients need to submit data to the server.
PATCH /api/profile HTTP/1.1
Content-Type: application/json
{
"displayName": "Alex"
}GET requests generally place retrieval parameters in the URL, such as query parameters, rather than relying on a request body. Although HTTP does not categorically forbid a body on GET, clients and servers should not assume interoperable support for GET request bodies.
Content-Type Matters
When a request contains structured data, the Content-Type header tells the server how to interpret the body.
Content-Type: application/jsonJSON is common for REST APIs, but HTTP supports many media types. An API may accept JSON, form data, multipart requests, or another representation depending on its contract.
Accept vs Content-Type
These two headers describe different things. Content-Type describes the representation contained in the request or response body. Accept tells the server which response media types the client is willing to receive.
POST /api/users HTTP/1.1
Content-Type: application/json
Accept: application/jsonHTTP Status Codes for GET
GET responses can use different status codes depending on the result.
| Status | Typical meaning |
|---|---|
| 200 OK | Resource retrieved successfully |
| 304 Not Modified | Cached representation can be reused |
| 404 Not Found | Requested resource was not found |
| 403 Forbidden | Server understood the request but refuses access |
HTTP Status Codes for POST
POST can result in several statuses depending on the operation.
| Status | Typical meaning |
|---|---|
| 201 Created | A new resource was created |
| 200 OK | Operation completed and a response representation is returned |
| 202 Accepted | Request accepted for processing, often asynchronously |
| 400 Bad Request | Request cannot be processed because it is invalid |
| 409 Conflict | Request conflicts with the current resource state |
HTTP Status Codes for PUT and PATCH
| Status | Typical use |
|---|---|
| 200 OK | Update succeeded and a response representation is returned |
| 201 Created | A resource was created by the operation |
| 204 No Content | Operation succeeded without a response body |
| 400 Bad Request | Request data is invalid |
| 404 Not Found | Target resource does not exist when required by the API |
| 409 Conflict | Operation conflicts with the current resource state |
Idempotency Explained
Idempotency describes the effect of repeating the same request. A method is idempotent when multiple identical requests have the same intended effect on server state as a single request.
Idempotency does not mean that every response will be byte-for-byte identical. For example, response headers, timestamps, or other metadata can differ. The important property concerns the intended effect of repeated requests.
| Method | Idempotency |
|---|---|
| GET | Idempotent |
| POST | Not inherently idempotent |
| PUT | Idempotent |
| PATCH | Not inherently idempotent |
Safety vs Idempotency
Safety and idempotency are related but different concepts. A safe method is intended only for retrieval or other read-oriented semantics. An idempotent method can modify state while still producing the same intended state when repeated.
GET is both safe and idempotent. PUT is idempotent but not safe. POST is neither safe nor inherently idempotent. PATCH is not inherently idempotent and is not safe.
Why Idempotency Matters for Retries
Networks can fail after a server receives a request but before the client receives the response. This creates uncertainty: the client may not know whether the operation succeeded.
Retrying an idempotent operation is generally easier to reason about because repeating the request should not introduce an additional intended state change. Non-idempotent operations require more care.
For important POST operations such as payments or order creation, APIs can use application-level idempotency keys when appropriate. An idempotency key allows the server to recognize repeated attempts belonging to the same logical operation.
POST /api/payments
Idempotency-Key: 9c2d7f10-exampleThe exact behavior of an idempotency key is an API-specific contract. Clients should follow the provider's documentation rather than assuming that every POST endpoint supports this mechanism.
Caching and GET
GET has important caching semantics because it is safe and commonly used to retrieve representations. HTTP caches can use response headers such as Cache-Control, ETag, and Last-Modified to determine whether a stored response can be reused or revalidated.
GET /api/products/123 HTTP/1.1
If-None-Match: "abc123"If the representation has not changed, the server may respond with 304 Not Modified, allowing the client or intermediary cache to reuse the stored representation.
Can POST, PUT, or PATCH Be Cached?
Caching rules are more restrictive and less common for POST, PUT, and PATCH than for GET. Whether a particular response can be cached depends on HTTP caching rules, response metadata, the method, and the behavior of the caching system.
In normal application development, GET should be the default method when the operation is simply retrieving a resource and you want conventional HTTP caching behavior.
GET vs POST for Search
Search endpoints sometimes create confusion because a search request can contain a large or complex set of parameters. A simple search is often represented with GET query parameters.
GET /api/search?q=javascript&category=frontend&page=2For more complex search systems, an API may use POST with a structured body. This can be useful when the query is too complex for a practical URL or when the API's design requires POST semantics.
POST /api/search
Content-Type: application/json
{
"query": "javascript",
"filters": {
"category": "frontend"
},
"page": 2
}Using POST for search does not automatically make it a state-changing operation. The semantics depend on the endpoint, although GET remains the conventional choice for ordinary safe retrieval.
PUT vs PATCH Example
Imagine an API stores this profile:
{
"id": 42,
"name": "Alex",
"email": "[email protected]",
"theme": "dark",
"language": "en"
}A full replacement could use PUT:
PUT /api/profiles/42
Content-Type: application/json
{
"name": "Alex",
"email": "[email protected]",
"theme": "light",
"language": "en"
}A partial update could use PATCH:
PATCH /api/profiles/42
Content-Type: application/json
{
"theme": "light"
}The PATCH version communicates that only the theme needs to change, while PUT communicates replacement of the target representation.
Common Mistakes
Using GET to Change Data
A common API design mistake is putting state-changing actions behind GET endpoints.
GET /api/users/42/deleteThis conflicts with GET's safe semantics and can cause unexpected behavior because browsers, crawlers, prefetchers, and caches can issue GET requests automatically.
Treating POST as a Universal Method
POST can represent many operations, but using POST for every API operation removes useful HTTP semantics. If an endpoint only retrieves data, GET communicates that intention more clearly. If a resource is being replaced or partially modified, PUT or PATCH may communicate the operation more precisely.
Using PUT for Every Update
PUT can be appropriate for updates, but using it for a single-field change may require sending a large representation when the API follows replacement semantics. PATCH can be a better fit when the API explicitly supports partial modifications.
Assuming PATCH Is Always Idempotent
PATCH is not automatically idempotent. Some patch operations are naturally idempotent, while others can produce a different state every time they are repeated.
Confusing PUT With PATCH
The difference is not simply that PUT means update and PATCH means update. PUT has replacement semantics, while PATCH applies a partial modification. Treating both as interchangeable can create ambiguity about omitted fields and retry behavior.
Choosing the Right Method
- Use GET when the client needs to retrieve a resource or collection.
- Use POST when submitting data for processing or commonly creating a new resource in a collection.
- Use PUT when replacing a resource representation or creating/replacing a resource at a known URI according to the API contract.
- Use PATCH when applying a partial modification to an existing resource.
- Avoid using GET for operations that intentionally change server state.
- Consider idempotency when designing operations that may be retried.
- Follow the API's documented request and response formats rather than assuming every API uses the same conventions.
Practical REST API Example
Consider a simple users API. The same resource collection can expose several operations using different HTTP methods.
| Request | Purpose |
|---|---|
| GET /api/users | Retrieve users |
| GET /api/users/42 | Retrieve one user |
| POST /api/users | Create a user |
| PUT /api/users/42 | Replace user 42 |
| PATCH /api/users/42 | Partially modify user 42 |
This pattern gives the API a predictable structure and allows clients to communicate their intended operation through standard HTTP semantics.
Using HTTP Request Tools During Development
HTTP request builders are useful when testing GET, POST, PUT, and PATCH endpoints because they allow you to inspect the complete request method, URL, headers, query parameters, and body before sending it.
Mock API generators can also help frontend developers test different request and response scenarios before a real backend is available. Response formatters and HTTP status simulators are useful when inspecting response bodies and testing client-side handling of success and error statuses.
When an API uses GraphQL instead of REST, the request model is different because GraphQL commonly uses a single HTTP endpoint with queries and mutations. An endpoint tester can still be useful for checking connectivity and server responses.
GET vs POST vs PUT vs PATCH Cheat Sheet
| If you need to... | Usually consider |
|---|---|
| Read a resource | GET |
| Read a collection | GET |
| Create a resource in a collection | POST |
| Submit data for server-side processing | POST |
| Replace a known resource | PUT |
| Create or replace at a known URI | PUT |
| Change only selected fields | PATCH |
| Apply a partial modification | PATCH |
Frequently Asked Questions
What is the difference between GET and POST?
GET is primarily used to retrieve resources and is safe and idempotent. POST is used to submit data for processing and is commonly used to create resources. POST is generally not idempotent, so repeating the same request can produce additional effects.
What is the difference between PUT and PATCH?
PUT is generally used to replace a resource representation at a target URI, while PATCH is used to apply a partial modification. PUT is idempotent, while PATCH can be idempotent depending on the operation.
Is PATCH idempotent?
PATCH is not inherently idempotent. A PATCH operation that sets a field to a specific value can be idempotent, while an operation that increments or appends something may not be.
Can GET have a request body?
HTTP does not categorically prohibit a body on GET, but clients and servers should not assume interoperable support for GET request bodies. Query parameters are the conventional way to send retrieval filters and other GET parameters.
Why should you not use GET to delete or modify data?
GET is defined as a safe method and is intended for read-oriented semantics. Browsers, crawlers, prefetchers, and caching systems can issue GET requests without the user explicitly intending a state-changing operation, so modifying data through GET can lead to unintended effects.
Should I use PUT or PATCH for updating a resource?
Use PUT when the API contract calls for replacing the target representation or creating/replacing it at a known URI. Use PATCH when the API supports partial modifications and only selected fields need to change. The API contract should determine the exact behavior.
Is POST always used to create resources?
No. POST is commonly used to create resources in a collection, but its semantics are broader. It can also submit data for processing or trigger an operation such as starting a job or performing a workflow action.
Which HTTP method is best for API requests?
There is no single method that is best for every request. GET is appropriate for retrieval, POST commonly handles submissions and creation, PUT is used for replacement or create/replace semantics at a known URI, and PATCH is used for partial modification.
Conclusion
GET, POST, PUT, and PATCH communicate different intentions in HTTP. GET is used to retrieve resources and is both safe and idempotent. POST commonly submits data for processing or creates a new resource and is generally not idempotent. PUT is used for replacement or create/replace semantics at a known URI and is idempotent. PATCH applies partial modifications and may or may not be idempotent depending on the operation.
Choosing the appropriate method makes an API easier to understand and gives clients useful guarantees around caching, retries, and state changes. The most important distinction is to treat HTTP methods as semantic instructions rather than merely different ways to send data.