API Request Methods: GET, POST, PUT, PATCH, DELETE (2026)

Every time you call an API, the very first word of the request is a method: GET, POST, PUT, PATCH or DELETE. Pick the wrong one and you get an error, or worse, you quietly change data you only meant to read.

This guide explains what each one does in plain English, shows a real request and response for every method, covers the status codes you should expect back, and finishes with the mistakes that trip up almost everyone. No background needed.

What is a request method?#

An API request has a few parts: an address (the URL), a method, optional headers, and sometimes a body with data. The address says what you are talking about. The method says what to do with it.

If you think of an API as a restaurant, the address is the dish and the method is the verb in your order:

• GET: "Can I see the menu?"
• POST: "Please add a new order for table 4."
• PUT: "Replace my whole order with this one."
• PATCH: "Change my drink to a lemonade, keep everything else."
• DELETE: "Cancel my order."

If the idea of an API itself is still new, read what a REST API is first, then come back. These methods come from HTTP, the same language your browser uses, and they are defined in an official standard (RFC 9110).

The example we will use#

To keep things easy to follow, every example below uses the same made-up service: a bookshop API with a list of books. The addresses are examples, not a real service.

• /v1/books is the whole list of books.
• /v1/books/42 is one book, number 42.

So GET /v1/books/42 means "show me book 42." Here is book 42:

{
  "id": 42,
  "title": "The Pragmatic Programmer",
  "author": "Andrew Hunt",
  "price": 30.0,
  "in_stock": true
}

Keep this book in mind. We will read it, create a new one, replace it, edit it and delete it.

Two ideas that explain everything: safe and idempotent#

Before the five methods, learn two words. They look scary, but they are simple, and they explain why the methods behave differently.

Safe means the request does not change anything on the server. It only looks. You can send a safe request a thousand times and nothing breaks.

Idempotent means that sending the same request many times has the same effect as sending it once. Think of an elevator button: pressing "floor 5" five times still takes you to floor 5 once.

Why you should care: networks fail. If a request times out, you often do not know whether it reached the server. With an idempotent method you can safely retry. With a non-idempotent one, a retry might do the thing twice.

Keep this table handy. It answers most "which method should I use?" questions.

GET: read data#

GET asks for information and changes nothing. It is the most common method by far. Pasting a link into your browser sends a GET.

Get one book:

curl "https://api.example.com/v1/books/42"

Response:

HTTP/1.1 200 OK
Content-Type: application/json
 
{
  "id": 42,
  "title": "The Pragmatic Programmer",
  "author": "Andrew Hunt",
  "price": 30.0,
  "in_stock": true
}

Get a filtered list, using query parameters after the ?:

curl "https://api.example.com/v1/books?author=Hunt&in_stock=true&limit=10"

What to remember about GET

• All the details go in the URL, not in a body. A GET has no body.
• Because it is safe, results can be cached, which makes repeat reads fast.
• Never put secrets such as passwords in the URL. URLs end up in logs and browser history. Send API keys in a header instead.
• A GET must never change data. If an endpoint deletes something when you open it, it is built wrongly.

Common results: 200 OK (here is your data), 404 Not Found (no such book), 401 Unauthorized (you need a valid key).

POST: create something new#

POST sends data to the server so it can create something. You describe the new item in the request body, and the server decides its ID.

Add a new book:

curl -X POST "https://api.example.com/v1/books" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"title": "Clean Code", "author": "Robert Martin", "price": 28.5}'

Response:

HTTP/1.1 201 Created
Location: /v1/books/43
Content-Type: application/json
 
{
  "id": 43,
  "title": "Clean Code",
  "author": "Robert Martin",
  "price": 28.5,
  "in_stock": true
}

Notice three things:

1. The status is 201 Created, not just 200. It means "a new thing now exists."
2. The server chose the ID, 43.
3. A Location header points to the new item's address.

POST is also the catch-all for actions that do not fit the other methods, such as "send this email" or "run this search with a long body". Many APIs use it for those.

Common results: 201 Created, 400 Bad Request (your data is malformed), 409 Conflict (it already exists), 422 Unprocessable Content (the data is well-formed but not valid, such as a negative price).

PUT: replace something completely#

PUT replaces the item at an address with exactly what you send. You must send the whole item.

Replace book 42:

curl -X PUT "https://api.example.com/v1/books/42" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"title": "The Pragmatic Programmer", "author": "Andrew Hunt", "price": 27.0, "in_stock": true}'

Response:

HTTP/1.1 200 OK
 
{
  "id": 42,
  "title": "The Pragmatic Programmer",
  "author": "Andrew Hunt",
  "price": 27.0,
  "in_stock": true
}

PUT is idempotent: sending the same PUT ten times leaves book 42 in the same final state as sending it once. That makes it safe to retry.

Some APIs also let PUT create an item at an address you choose, for example PUT /v1/books/isbn-9780135957059. Check the documentation.

Common results: 200 OK or 204 No Content, 404 Not Found, 400 Bad Request.

PATCH: change part of something#

PATCH changes only the fields you send. Everything else stays as it was. This is the polite way to make a small edit.

Change just the price of book 42:

curl -X PATCH "https://api.example.com/v1/books/42" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"price": 25.0}'

Response:

HTTP/1.1 200 OK
 
{
  "id": 42,
  "title": "The Pragmatic Programmer",
  "author": "Andrew Hunt",
  "price": 25.0,
  "in_stock": true
}

The title, author and stock status are untouched. Only the price changed.

Is PATCH idempotent? It depends on how the change is written. "Set the price to 25" is idempotent: do it twice and the price is still 25. "Increase the price by 5" is not: do it twice and you add 10. Because the standard does not promise it, treat PATCH as not safe to blindly retry unless the API says otherwise.

Common results: 200 OK or 204 No Content, 404 Not Found, 422 Unprocessable Content.

PUT vs PATCH, side by side#

This is the most-asked question about methods, so here it is in one table. Starting with book 42 (title, author, price, in stock):

Rule of thumb: sending the whole item? Use PUT. Sending just a change? Use PATCH.

DELETE: remove something#

DELETE removes the item at an address.

curl -X DELETE "https://api.example.com/v1/books/42" \
  -H "Authorization: Bearer YOUR_API_KEY"

Response:

HTTP/1.1 204 No Content

204 No Content means "done, and there is nothing to send back." Some APIs return 200 OK with a short message instead.

What happens if you delete it twice? The first call removes the book. The second may return 404 Not Found, because it is already gone. That is still idempotent, because the state of the server is the same either way: the book does not exist. The status code can differ, but nothing extra was deleted.

Common results: 204 No Content, 200 OK, 404 Not Found, 403 Forbidden (you are not allowed to delete it), 409 Conflict (it is still in use).

Two more methods you will meet: HEAD and OPTIONS#

You can use APIs for years with just the five above, but two others show up in tools and error messages.

• HEAD is GET without the body. The server returns only the headers, such as the size or last-changed date. It is handy for checking "does this exist?" or "has it changed?" without downloading the data.
• OPTIONS asks the server what is allowed at an address. It also powers CORS preflight: before a web page at one site calls an API at another, the browser sends an OPTIONS request to check that it is permitted. If you ever see a confusing OPTIONS request in your browser's network tab, that is why.

All five methods compared#

The whole lifecycle in one example#

Here is how the five methods work together on one item, from birth to deletion:

That sequence is the backbone of almost every API that stores data.

Status codes by method#

The method says what you tried. The status code says how it went. Here are the ones you will see most:

A good habit: check the status code first, and only then read the data. Codes starting with 2 mean success, 4 means a problem on your side, and 5 means a problem on the server's side.

Common mistakes (and how to fix them)#

1. Using GET to change data. Browsers, search engines and link previews send GET requests on their own. If a GET can delete something, it eventually will. Use POST, PUT, PATCH or DELETE for anything that changes data.

2. Using POST for everything. It works, but you lose the benefits of the other methods: caching, safe retries and a clear meaning. Use the method that matches the action.

3. Using PUT when you meant PATCH. This is how fields get wiped by accident. If you are not sending the whole item, use PATCH.

4. Retrying a POST blindly. After a timeout, a second POST can create a duplicate order or payment. Use an idempotency key, or check whether the first one succeeded before retrying.

5. Forgetting the Content-Type header. When you send JSON in a body, add Content-Type: application/json. Without it, the server may reject the request with 415 Unsupported Media Type or read the body wrongly.

6. Sending a body with GET. Many servers ignore it. Put the details in the URL, or use POST if the search is large.

7. Ignoring a 405 error. It means the method is wrong for that address, not that the address is wrong. Look at the Allow header in the response, or the API documentation, to see which methods the address accepts.

Try each method yourself#

You do not need to build anything to see this work.

In your browser (GET only, 1 minute): paste any API URL that has a free plan into the address bar. You will see the JSON response. This is a GET.

In the terminal with cURL (all methods, 5 minutes):

# Read
curl "https://api.example.com/v1/books/42"
 
# Create
curl -X POST "https://api.example.com/v1/books" \
  -H "Content-Type: application/json" \
  -d '{"title": "Clean Code", "author": "Robert Martin"}'
 
# Change part of it
curl -X PATCH "https://api.example.com/v1/books/42" \
  -H "Content-Type: application/json" \
  -d '{"price": 25.0}'
 
# Remove
curl -X DELETE "https://api.example.com/v1/books/42"

In JavaScript with fetch:

const response = await fetch("https://api.example.com/v1/books/42", {
  method: "PATCH",
  headers: {
    "Content-Type": "application/json",
    Authorization: "Bearer YOUR_API_KEY",
  },
  body: JSON.stringify({ price: 25.0 }),
});
 
if (!response.ok) {
  throw new Error(`Request failed with status ${response.status}`);
}
 
const book = await response.json();
console.log(book);

The only things that change between the five methods are the method name, the address, and whether there is a body.

In APIHiver's playground: you can test endpoints in your browser, with your key filled in for you, and see the method, the request and the response side by side. See how to use a REST API for a full walk-through.

Myths about request methods#

• "POST is more secure than GET." Not by itself. A POST body is not shown in the URL, but both are sent over the network the same way. What protects your data is HTTPS and proper authentication, not the method.
• "PUT and POST are the same." They are not. POST creates a new item and lets the server choose the ID. PUT puts an item at a specific address and is safe to repeat.
• "DELETE always erases the data forever." Often it only hides it. Read the API's documentation.
• "Every API supports all five." Many read-only APIs, such as weather or currency data, only support GET.
• "The method decides what happens." The method is a promise about intent, but the server's code does the work. A badly built API can break these rules, which is why you should always read its documentation.

Summary#

• GET reads, POST creates, PUT replaces, PATCH edits part, DELETE removes.
• GET is safe and never changes data. GET, PUT and DELETE are idempotent, so you can retry them. POST is not, so protect it with an idempotency key.
• PUT replaces everything, and a missing field may be erased. Use PATCH for small edits.
• Check the status code first: 2xx success, 4xx your mistake, 5xx the server's.
• Many APIs only support some of the methods, so always follow the API's own documentation.

Now that you know the verbs, see them used on real APIs in our guides: Best Travel APIs for Developers, Hotel API & Hotel Booking API compared, and REST API vs SOAP API.