API Methods: GET, POST, PUT, PATCH, DELETE Explained
Whether you are fetching weather updates for a smart home or processing a payment for an online purchase, being able to read and write data over an API is critical. At the heart of that data exchange are API methods: the HTTP verbs that tell the server what you want to do with a resource. GET to read, POST to create, PUT and PATCH to update, DELETE to remove.
This guide covers what each API method does, the difference between safe and idempotent methods, how to choose between similar methods like PUT and PATCH, and how method choice changes in 2026 with AI agents that retry and MCP endpoints that need idempotency keys. If you have not yet built a REST API, our REST API tutorial walks through the implementation side with Node.js and Express.
What are API methods?
API methods are the actions a client can request against a resource exposed by an API. In REST APIs (which are the most common type of API in production), these methods are the standard HTTP verbs: GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS. The method is set on the request, and it tells the server whether to retrieve data, create something new, update an existing resource, or remove one.
You will sometimes hear “API method” used loosely to mean an endpoint or operation. In strict usage, the method is the verb (GET, POST, etc.) and the endpoint is the URL.
HTTP methods at a glance
| Method | Use | Has body? | Safe? | Idempotent? |
|---|---|---|---|---|
| GET | Retrieve a resource or list | No | Yes | Yes |
| POST | Create a new resource | Yes | No | No |
| PUT | Replace an existing resource | Yes | No | Yes |
| PATCH | Partially update a resource | Yes | No | Sometimes |
| DELETE | Remove a resource | No | No | Yes |
| HEAD | Retrieve headers only | No | Yes | Yes |
| OPTIONS | Discover supported methods | No | Yes | Yes |
“Safe” means the method does not modify server state. “Idempotent” means calling the method multiple times has the same effect as calling it once.
Safe vs. idempotent methods
These two characteristics shape almost every method decision.
Safe methods (GET, HEAD, OPTIONS) are read-only. They retrieve data without modifying the state of the server, and they should have no side effects. A client, proxy, or browser can call them speculatively without worrying about consequences.
Idempotent methods (GET, HEAD, OPTIONS, PUT, DELETE) can be called multiple times without changing the result beyond the initial application. DELETE /users/123 is idempotent: the user is gone after the first call, and additional calls do not delete more users. PUT /users/123 replaces the user with the same data on each call, ending in the same state.
POST is the odd one out: it is neither safe nor idempotent. Two identical POST requests create two different resources by default. This is why retry logic and idempotency keys (covered below) matter most for POST.
PATCH is conditionally idempotent: it depends on how you implement the patch. JSON Patch and JSON Merge Patch can both be made idempotent, but a custom patch format (“increment counter by 1”) is not.
GET, POST, PUT, PATCH, DELETE in depth
GET
The GET method retrieves data from a server without modifying it.
- Client request: The client sends a GET request to a specific endpoint (for example,
/users/123). - Server response: The server processes the request, locates the resource (if it exists), and returns a representation of the resource’s current state in the response body.
- Example: A GET request to a
/productsendpoint might return a list of all available products in JSON format.
GETs should never change state. If your endpoint modifies data on a GET, you are violating REST conventions and breaking browser caches, proxies, and prefetch behavior.
POST
The POST method creates new resources on the server.
- Client request: The client sends a POST request to a collection endpoint (for example,
/orders). - Request body: Contains the data for the new resource.
- Server response: The server processes the request, creates the new resource, and usually returns the created resource (with its assigned ID) in the response body, alongside a
201 Createdstatus code and aLocationheader pointing to the new URL. - Example: A POST request to
/userswith user details in the body creates a new user account.
POST is not idempotent. Two identical POSTs create two separate resources. If you want clients to retry safely, give them an Idempotency-Key header to send (see the 2026 section below).
PUT
The PUT method replaces an existing resource with the data provided.
- Client request: The client sends a PUT request to a specific resource endpoint (for example,
/products/456). - Request body: The complete representation of the updated resource.
- Server response: The server replaces the existing resource with the new data and returns the updated resource or a success status code.
- Example: A PUT request to
/users/123with updated user information overwrites the existing user data entirely.
PUT is idempotent. Calling it twice with the same body leaves the resource in the same state.
PATCH
The PATCH method partially updates an existing resource. Instead of replacing the whole thing (which is what PUT does), PATCH lets clients modify specific fields.
- Client request: The client sends a PATCH request to a resource endpoint (for example,
/users/123). - Request body: A set of instructions describing the changes. Most APIs use JSON Merge Patch (the partial object) or JSON Patch (an explicit operations array).
- Server response: The server applies the changes and returns the updated resource or a success code.
- Example: A PATCH request to
/users/123containing{ "email": "new@example.com" }updates only the email field, leaving other fields untouched.
PATCH is the right choice when the client only wants to change a subset of fields. Use PUT only when the client is sending the entire resource.
DELETE
The DELETE method removes a resource from the server.
- Client request: The client sends a DELETE request to a specific resource endpoint (for example,
/users/123). - Server response: The server removes the resource and typically returns
204 No Content(empty body) or200 OKwith a confirmation. - Example: A DELETE request to
/orders/789removes the order.
DELETE is idempotent: the second call returns the same outcome as the first, because the resource is already gone. Many APIs return 404 Not Found on subsequent calls; some return 204 regardless. Either is acceptable, but pick one and document it. Our HTTP status code reference covers the full set of response codes you will return from these methods.
HEAD and OPTIONS
Two methods you will see less often but should know.
HEAD is identical to GET but returns only the headers, not the body. Useful for checking whether a resource exists or has changed, without downloading the full payload. Common for HTTP caching and link checkers.
OPTIONS asks the server what HTTP methods it supports on a given endpoint. Browsers send OPTIONS requests automatically as part of CORS preflight checks. You rarely call OPTIONS manually in your application code.
How to choose the right API method
The decision rules that come up most often:
- Reading data? Use GET. Always. If the request modifies state, you picked the wrong verb.
- Creating a new resource the server assigns an ID to? POST to the collection endpoint (
POST /orders). - Creating or updating a resource at a URL you know? PUT to the specific resource (
PUT /users/123). - Changing some fields on an existing resource? PATCH.
- Removing a resource? DELETE.
- Performing an action that does not fit CRUD (search, login, send-email, run-job)? POST to a named endpoint (
POST /searches,POST /sessions). REST purists will tell you to model it as a resource; in practice, naming the endpoint after the action is fine for non-CRUD operations.
The mistake people make most often is using POST for everything. POST works for any operation the server understands, but it gives up the safety guarantees and caching behavior the more specific verbs provide. Following these defaults is one of the core API design principles that pays off across the lifetime of an API.
API methods beyond REST
The HTTP verbs above are the REST vocabulary. A few other API styles use different conventions.
- SOAP APIs rely on XML for data exchange and use a strict set of rules and protocols. SOAP APIs are still common in enterprise applications where security and reliability are paramount.
- GraphQL APIs typically expose a single POST endpoint and use a query language in the request body. There is no per-method semantic distinction; the query itself describes what to do.
- Webhook APIs invert the pattern: instead of you calling an API, the API calls you. The provider sends a POST to a URL you provide when an event occurs.
- RPC APIs (including gRPC) let clients call remote functions. The “method” in RPC is the function name, not an HTTP verb.
Most public APIs are REST, so the HTTP methods above are what you will use 95% of the time.
API methods in 2026: idempotency, agents, and MCP
A few wrinkles that did not exist five years ago.
Idempotency keys for POST. When a client (especially an AI agent or a serverless function) retries a request, you do not want a second resource created. The convention that emerged from Stripe’s API and is now widely used across payments and infrastructure APIs: clients send an Idempotency-Key: <unique-string> header on POST requests, and the server returns the same response on retry. This makes POST safe to retry without becoming truly idempotent at the protocol level. An IETF draft is working toward standardizing the header.
AI agent retries. AI agents retry aggressively when they get errors. Two practical defenses: accept Idempotency-Key on every write endpoint, and return 429 Too Many Requests with a Retry-After header when you are overloaded, rather than 5xx. Agents respect 429 better than 5xx.
MCP-exposed APIs use the same methods. When you expose your REST API as an MCP server (which the WSO2 AI Gateway can auto-generate from any OpenAPI spec), the same HTTP methods still apply. The agent runtime translates the model’s intent into the same GET, POST, PUT, PATCH, DELETE calls you already support. Designing for idempotency and clean status codes pays off twice: for human integrators and for agent traffic.
Next steps
API methods are the vocabulary of REST. Picking the right verb makes your API readable to every HTTP client in the world and unlocks decades of tooling. Once your methods are right, the next question is whether the codes you return match what your consumers see in practice. Start a 14-day Moesif free trial to watch method-by-method usage on your own API in real time. No credit card required.
Frequently asked questions
What are the main API methods? GET (read), POST (create), PUT (replace), PATCH (partial update), and DELETE (remove). HEAD and OPTIONS exist for HTTP metadata and CORS but are less common in application code.
What is the difference between PUT and PATCH? PUT replaces the entire resource with the request body. PATCH modifies specific fields without touching the rest. Use PATCH when you only want to change a subset of fields; use PUT when you are sending the full resource.
What is an idempotent API method? A method that can be called multiple times with the same effect as calling it once. GET, HEAD, OPTIONS, PUT, and DELETE are idempotent. POST is not.
Can you use POST instead of PUT or PATCH? Technically yes, but you lose the semantic benefits. PUT and PATCH tell HTTP clients, proxies, and tooling what your endpoint actually does. Using POST for everything works but throws away signal.
Do API methods only apply to REST APIs? HTTP methods (GET, POST, etc.) are an HTTP concept. REST APIs use them with specific meanings. GraphQL, gRPC, and SOAP have different conventions for what an “API method” looks like.
What HTTP method should I use for search? POST to a /searches endpoint is fine when the search parameters are too large for a query string, or when the search creates a saved record. Use GET with query parameters when the search is simple and stateless.
Related Articles
API Strategy
Leveraging AI For a Better API Strategy
Learn how to leverage AI to build and fortify your API strategy. Improve design, governance, documentation, and align APIs with business outcomes.
API Strategy
The 5 Best Mixpanel Alternatives of 2025
Learn about the best Mixpanel alternatives to determine the right analytics solution for your use case.
API Development
How to Leverage Moesif Effectively for API Observability
Effectively leverage Moesif for API observability through best practices for integration, event enrichment, custom actions, and engineering workflow integrat...
API Strategy
How to Build an Internal Chargeback Model for Your API and AI Usage Using Moesif
Use Moesif to implement internal chargebacks and enable precise API and AI cost attribution for better transparency and resource optimization.