HTTP Request Methods

HTTP request methods communicate the intended operation and semantics of a request. Frontend engineers commonly use GET to retrieve data, POST to create or trigger processing, PUT to replace a resource, PATCH to partially update it, and DELETE to remove it.

HTTP methods are part of the request sent by `fetch()` to a server. The method tells the server how the client intends to interact with the target resource; the URL identifies the target, while headers and the body carry additional information.

`GET` is normally used to retrieve a representation of a resource and should not change server state. `POST` submits data for processing and is commonly used to create a resource or trigger an operation. A request body is common with `POST`, although HTTP does not require every POST request to have one.

`PUT` generally means replacing the target resource with the supplied representation. `PATCH` is intended for a partial modification, so the request can contain only the fields that need to change. The exact application behavior still depends on the API contract.

`DELETE` requests removal of the target resource. HTTP also defines other methods, such as `HEAD` and `OPTIONS`, but GET, POST, PUT, PATCH, and DELETE are the methods most often encountered when building frontend API clients.

Some methods have important semantic properties. GET, PUT, and DELETE are defined as idempotent, meaning repeating the same request should have the same intended effect as making it once, although the response or surrounding side effects can differ. GET is also safe, meaning it is intended for read-only interaction with the resource.

Key points

• Use `GET` to retrieve data without requesting a state change.
• Use `POST` to submit data for processing, commonly for creation or actions.
• Use `PUT` for replacement semantics and `PATCH` for partial modification.
• Use `DELETE` to request resource removal.
• Method semantics are API contracts; the server determines the actual application behavior.

Interview questions

What are the main HTTP methods you use from a frontend application?

GET is typically used to retrieve data. POST submits data for processing, often to create something or trigger an operation. PUT generally replaces a resource, PATCH partially updates it, and DELETE requests removal. The exact behavior should follow the API's documented contract.

How would you make a PATCH request with fetch()?

I would pass `method: "PATCH"` in the `fetch()` options. If I am sending JSON, I would set the `Content-Type` header and serialize the object with `JSON.stringify()`. I would then inspect the response status and parse the response body if appropriate. The exact fields sent should match the API's PATCH contract.

What does idempotent mean in HTTP?

An operation is idempotent when making the same request multiple times has the same intended effect on the resource as making it once. HTTP defines GET, PUT, DELETE, HEAD, OPTIONS, TRACE, and CONNECT as idempotent methods, while POST is not defined as idempotent. Idempotency does not mean that every response is identical; for example, a repeated DELETE can receive a different status after the resource has already been removed. It is mainly about the intended effect of repeated requests.

Why shouldn't a frontend use GET for an operation that changes data?

GET is defined as a safe method, so clients and intermediaries can treat it as a read-only operation. Using it for a state-changing action violates the method's intended semantics and can cause surprising behavior with caching, prefetching, crawling, or retries. A state-changing operation should use a method whose semantics match the operation, such as POST, PUT, PATCH, or DELETE. The final choice depends on the API design.

What is the practical difference between PUT and PATCH in a frontend API client?

PUT communicates replacement semantics for the target resource, so the client generally supplies the representation that should replace the existing one. PATCH communicates a partial modification, allowing the client to send only the changes it wants to make. Whether omitted fields are cleared, preserved, or handled in another way is determined by the API contract. I would therefore follow the backend's documented request schema rather than assuming a universal field-merging behavior.