HTTP methods – REST APIs

HTTP methods, also known as verbs, define the type of action a client can perform on a resource in a RESTful API. Each method represents a specific operation that defines the endpoint’s intent on a resource. Here is a list of the most frequently used methods, what they are for, and their expected success status code:

Method	Typical role	Success status code
GET	Retrieve a resource (read data).	200 OK
POST	Create a new resource.	201 CREATED
PUT	Replace a resource.	200 OK or 204 No Content
DELETE	Delete a resource.	200 OK or 204 No Content
PATCH	Partially update a resource.	200 OK

Next, we explore the commonly used status codes.

HTTP Status code

HTTP status codes are part of the HTTP response and provide the client with information about the success or failure of their request; the status of the request.Status codes touching similar subjects are grouped under the same broad “hundredth” categories:

1XX (informational) codes indicate that the request was received and the process is continuing, such as 100 Continue and 101 Switching Protocols .
2XX (successful) codes indicate that the request was received successfully.
3XX (redirection) codes indicate that the client must take further action to complete the redirection request.
4XX (client error) codes indicate an error on the client’s part, such as validation errors. The client sent an empty required field, for example.
5XX (server error) codes indicate that the server failed to fulfill an apparently valid request and that the client cannot do anything about it (retrying the request is not an option).

The following table explains some of the most common ones:

Status code	Role
200 OK	Indicates the request has succeeded. It usually includes data related to the resource in the response body.
201 CREATED	Indicates the has succeeded and the system created a resource. It should also include a Location HTTP header pointing to the newly created resource and can include the new entity in the response body.
202 ACCEPTED	Indicates the request has been accepted for processing but is not processed yet. We use this code for asynchronous operations. In an event-driven system (see Chapter 17 , Introduction to Microservices Architecture ), this could mean that an event has been published, the current resource has completed its job (published the event), but to know more, the client needs to contact another resource, wait for a notification, just wait, or can’t know.
204 NO CONTENT	Indicates the request has succeeded with no content in the response body.
302 FOUND	Indicates that the requested resource resides temporarily under a different URL specified in the Location header. We commonly use this status code for redirection.
400 BAD REQUEST	Indicates that the server could not understand or process the request. This usually relates to a validation error like a bad input or a missing field.
401 UNAUTHORIZED	Indicates that the request requires user authentication to access the resource.
403 FORBIDDEN	Indicates that the server understood the request but refused to authorize it. This usually means the client lacks the access rights for the resource (authorization).
404 NOT FOUND	Indicates the resource does not exist or was not found. REST APIs often return this from valid endpoints.
409 CONFLICT	Indicates that the server cannot complete the request due to a conflict with the current state of the resource. A typical scenario would be that the entity has changed between its read operation ( GET ) and the current update ( PUT ) operation.
500 INTERNAL SERVER ERROR	Indicates that an unhandled error occurred on the server side and prevented it from fulfilling the request.

Now that we covered the HTTP methods and status codes, we look at how to pass more metadata between the client and the server.

HTTP methods – REST APIs

Leave a Reply Cancel reply

You may also like

Leave a Reply Cancel reply

You may also like

The second endpoint – REST APIs

Liskov substitution principle (LSP) – Architectural Principles