WEB DEVELOPMENT

HTTP Methods Explained: GET, POST, PUT, PATCH, DELETE

HTTP methods describe the intended action for a request. Choosing the right method makes web APIs easier to understand and use consistently.

LOVE COMPUTER•Practical Tutorial

What is an HTTP method?

An HTTP method indicates the intended action for a request. Methods are part of the request line and help clients, servers, caches, and proxies understand how a resource is being accessed or changed. The server still decides what operations are supported at a given route.

Common HTTP methods

Method	Typical purpose	Safe?	Idempotent?
`GET`	Retrieve a representation	Yes	Yes
`HEAD`	Retrieve headers without response body	Yes	Yes
`POST`	Submit data or trigger processing	No	Not generally
`PUT`	Create/replace the target representation	No	Yes
`PATCH`	Apply a partial modification	No	Not necessarily
`DELETE`	Request removal of a resource	No	Yes in intended effect
`OPTIONS`	Discover communication options	Yes	Yes

Safe means the method is defined as read-only in intent. Idempotent means repeating the same request has the same intended effect as making it once; responses may still differ.

GET vs POST

Use GET to retrieve data without changing server state. Use POST when submitting a new command or data for processing, such as creating an order or starting a search operation that is not modeled as a simple retrieval. Do not put secrets in a URL query string: URLs can appear in browser history, logs, and referrer data.

PUT vs PATCH

PUT generally represents replacing the target resource with the supplied representation (or creating it where the API defines that behavior). PATCH describes applying a set of changes. For example, replacing all editable profile fields could be PUT; changing only the display name could be PATCH. The exact request format is defined by the API.

DELETE and repeated requests

DELETE asks the server to remove the target resource. It is considered idempotent in HTTP semantics: after the resource is deleted, repeating the request should not cause an additional intended deletion effect. The server may return different status codes, such as success for the first request and not found for a later one.

Example API routes

GET    /api/users/12       # read user
POST   /api/users          # create user
PUT    /api/users/12       # replace user representation
PATCH  /api/users/12       # update selected fields
DELETE /api/users/12       # delete user

These are illustrative conventions, not a universal rule. Good APIs document supported methods, request bodies, authorization requirements, and expected status codes.

Common status codes

200 OK: request succeeded, often with a response body.
201 Created: a resource was created.
204 No Content: request succeeded and there is no response body.
400 Bad Request: request is malformed or invalid.
401 Unauthorized: authentication is missing or invalid.
403 Forbidden: caller is not allowed to perform the action.
404 Not Found: target resource was not found or is not exposed.
405 Method Not Allowed: method is not supported for the target resource.

Best practices

Use methods according to their semantics, not merely because a framework makes one convenient.
Protect state-changing operations with authentication, authorization, validation, and appropriate CSRF defenses for cookie-based browser sessions.
Do not rely on obscurity of a URL to protect an operation.
Document whether retries are safe, especially for payment or order creation endpoints.

Frequently asked questions

Which HTTP methods are safe?

GET, HEAD, OPTIONS, and TRACE are defined as safe, although many applications primarily use GET, HEAD, and OPTIONS. Servers should not attach unintended state changes to safe requests.

Which methods are idempotent?

GET, HEAD, PUT, DELETE, OPTIONS, and TRACE are defined as idempotent. POST and PATCH are not necessarily idempotent.

Can GET have a request body?

HTTP does not define generally useful semantics for GET content, and some implementations reject it. Put ordinary filters in query parameters or use a documented API design.

Should I use POST for every API call?

No. Choose the method that matches the operation and HTTP semantics; consistent methods make APIs easier to understand and operate.

Does DELETE always erase data permanently?

No. The API may soft-delete, queue deletion, or apply retention policies. The contract should explain the behavior.

What is the difference between 401 and 403?

401 indicates valid authentication is absent or not accepted; 403 indicates the server understood the request but refuses authorization.

Learning tip: Try the examples in a test project before using them in production. Check official documentation for behavior that depends on a tool, database, or version.