HTTP Methods
By the Syncfusion DevTutorials team · Last updated
Learn GET, POST, PUT, PATCH and DELETE, what safe and idempotent mean, and how an Idempotency-Key stops a retried payment from charging twice.
An HTTP method is a command that tells the server what the client wants to do with a resource. Every HTTP request starts with a method. The method explains the purpose of the request, such as reading data, creating new data, updating existing data, or deleting data. For example, GET is used to read data, POST is used to create data, PUT is used to replace data, PATCH is used to update part of the data, and DELETE is used to remove data. Using the correct method makes APIs easier to understand and helps clients and servers communicate clearly.
Watch a Customer Pay Twice
Asha orders two lattes and taps Pay. The network is slow. The app waits for a response, gives up, and sends the same payment request again. Press Run. The Requests box contains the original payment request and its retry.
Program.cs — a retried POST pays twice
Look at the final response. The server has created two payments of ₹440. Asha was charged twice for the same order.
In simple words: the server cannot tell whether the second request is a retry or a brand-new payment. Later in this lesson, you will learn how to fix this using an Idempotency-Key.
TL;DR
- GET reads data.
- POST creates new data.
- PUT replaces existing data.
- PATCH updates part of existing data.
- DELETE removes data.
- A safe method does not change anything on the server.
- An idempotent method has the same result whether it is sent once or many times.
- GET, PUT, and DELETE are idempotent.
- POST is not idempotent.
- Network problems can cause requests to be retried.
- Retrying a POST can accidentally create duplicate orders or payments.
- An Idempotency-Key makes POST requests safe to retry.
- If a path exists but the HTTP method is not allowed, the server returns
405 Method Not Allowed.
A Real-World Example
Think about pressing a lift button. You press the button for floor 3. The lift is slow, so you press the button again. You may even press it several more times. The lift still goes to floor 3 only once. This is called idempotent behavior. Whether you press the button once or many times, the result stays the same. Now think about a coffee machine.
Every time you press the Make Coffee button, a new cup of coffee is prepared. Press it twice and you get two cups. This is not idempotent because every press creates something new. A POST request works in a similar way. Each request usually creates a new resource. That is why retrying a POST can be risky.
Without an Idempotency-Key, a retry becomes a second payment. With an Idempotency-Key, the server recognises the retry and returns the original result.
What You Will Learn
In this lesson, you will learn:
- The five common HTTP methods and when to use them.
- What safe and idempotent mean.
- Why a retry can create duplicate payments.
- How an Idempotency-Key makes POST requests safe to retry.
- Why using GET to change data is a serious mistake.
The Five Methods
One resource can support different HTTP methods. In this example, the resource is an order. Press Run and review the responses.
Five methods working on the same resource. Each method performs a different action.
Program.cs — one order, five methods
| Method | Purpose | Example Response | Request Body |
|---|---|---|---|
GET /orders/101 | Read order 101 | 200 OK and the order | No |
POST /orders | Create a new order | 201 Created, a Location header, and the order | Yes |
PUT /orders/102 | Replace order 102 completely | 200 OK and the updated order | Yes, complete object |
PATCH /orders/102 | Update part of order 102 | 200 OK and the updated order | Yes, changed fields only |
DELETE /orders/102 | Delete order 102 | 204 No Content | No |
The final request reads order 102 again and receives 404 Not Found because the order was deleted.
PUT vs PATCH
Both methods modify existing data, but they work differently.
PUT
- Replaces the entire resource.
- The client sends all fields.
- Missing fields may be removed or overwritten.
PATCH
- Updates only specific fields.
- The client sends only the fields that change.
- Useful for small updates such as changing a status.
In C#, app.MapGet, MapPost, MapPut, MapPatch and MapDelete connect a method and a path to your code. In Hono, the same job is done by app.get, app.post, app.put, app.patch and app.delete.
Safe and Idempotent
These two concepts are important when working with HTTP methods.
Safe
A method is safe when it does not change anything on the server. Safe methods only read data. For example: GET /menu This request reads information but does not create, update, or delete anything.
Idempotent
A method is idempotent when sending it multiple times results in the same final state as sending it once. For example:
- Updating the same item with the same data multiple times produces the same result.
- Deleting an item multiple times still leaves the item deleted.
Safe methods do not change data. Idempotent methods can be repeated without changing the final result. POST is neither.
| Method | Safe? | Idempotent? |
|---|---|---|
| GET | Yes | Yes |
| PUT | No | Yes |
| DELETE | No | Yes |
| PATCH | No | Not always |
| POST | No | No |
See Idempotent in Action
The next example sends the same PUT twice and then the same DELETE twice.
Program.cs — PUT twice, DELETE twice
Both PUT requests produce the same result. The second request does not create any additional changes.
That makes PUT idempotent. The first DELETE removes the order and returns 204 No Content. The second DELETE finds nothing and returns 404 Not Found. Although the responses are different, the final state is still the same: the order does not exist. That is why DELETE is also considered idempotent.
Make a Retry Safe
POST is not idempotent. If a client retries a POST request, the server may create another order or process another payment. To prevent this problem, clients can send an Idempotency-Key header. The key should be unique for each real operation. When the same key is received again, the server knows that it is a retry and returns the original result instead of creating a new one.
Program.cs — an Idempotency-Key stops the second charge
The retry uses the same key: order-101-pay-1 The server recognizes it as the same payment request and returns the first payment instead of processing another charge. As a result, Asha pays only once.
The client makes the key, not the server. Make one new key for each real payment, and reuse it only for retries of that payment. Big payment APIs work exactly this way.
The Wrong Method
Sometimes a path exists but does not support the method being used. In that case, the server responds with: 405 Method Not Allowed
The response also includes an Allow header that lists the supported methods.
Program.cs — the wrong method gets 405
In ASP.NET Core, 405 Method Not Allowed and the Allow header are usually handled automatically. In Hono, you may need to configure this behavior yourself.
Never change data with GET. Browsers, link previews and search robots open GET links on their own. If GET /orders/101/cancel cancels an order, a chat app that shows a preview of the link can cancel it. Use POST, PUT, PATCH or DELETE for anything that changes data.
Where You See This
- Payment APIs use Idempotency-Key headers to prevent duplicate charges.
- Mobile apps retry requests when the network is unreliable.
- Browsers sometimes preload or preview GET requests automatically.
- Order systems use different HTTP methods to create, update, and remove data.
Common mistakes
| Problem | Cause | Solution |
|---|---|---|
| Customer is charged twice | POST request was retried and processed twice | Use an Idempotency-Key and validate it on the server |
| Orders are cancelled unexpectedly | A GET request changes data and was triggered automatically | Replace GET with POST, PUT, PATCH, or DELETE |
405 Method Not Allowed | The path exists but the wrong method was used | Check the Allow header and use one of the supported methods |
| Data disappears after a PUT | PUT replaces the entire resource and not all fields were sent | Send all fields with PUT or use PATCH instead |
Exercises
What to Remember
- GET reads, POST creates, PUT replaces, PATCH changes part, DELETE removes.
- Safe means that it changes nothing. Idempotent means that repeats do no extra harm.
- POST is not idempotent, so a retry can make a second order or payment.
- An Idempotency-Key header makes a POST safe to retry.
- Never change data with GET.
Next: REST API Design and URL Naming. You will turn action-style URLs into clean resource URLs, and you will add filtering, sorting and pages.