Commonly used Http methods in RESTful services

Carvia Tech | May 05, 2019 | 5 min read | 18 views


Most commonly used HTTP methods are GET, POST, PUT, PATCH and DELETE.

We will cover all of these one by one in detail.

POST

this method is used to Create new resources on server. normally Http 201 (Created) response is returned by server along with the ID of the newly created reosurce. Server may return 409 (Conflict), if the resource already exists or 404 (Not found). example:

Request URL
POST /customer
Request Body
{
 "name": "carvia",
 "email": "carvia.tech@mail.com"
}
GET

this method is used to Read resource from server and not change it. Server returns Http 200 (OK) if resource is found, 404 (Not Found) if id is not found or 400 (Bad request). It should never modify any resource on server i.e. GET should be idempotent, which means that making multiple identical requests have same effect as calling it exactly once. example:

Request URL
GET /customer/{id}
Response Body
{
 "id": "<uuid>",
 "name": "carvia",
 "email": "carvia.tech@mail.com"
}
PUT

this method is used to update or replace en existing resource. Server returns 200 (OK) or 204 (No Content), 404 (Not found) if Id not found.

PATCH

this method is used to update/modify an existing reosurce. The PATCH request only needs to contain the changes to the resource, not the complete resource, thus only difference is sent to server instead of complete payload. Server returns 200 (OK) or 404 (Not found) if Id not found.

DELETE

this method is used to delete an existing resource on server. Server returns 405 (Method not allowed) if operation is not supported, 200 (OK) if item is deleted, 404 (not found) if Id is not found or invalid. HTTP spec-wise, DELETE operations are idempotent. If you DELETE a resource, it’s removed. Repeatedly calling DELETE on that resource ends up the same: the resource is gone.

HTTP Status Codes in RESTful APIs

HTTP defines standard status codes that can be used to convey the results of a client’s request. The status codes are divided into the five categories presented below.

HTTP Status Codes
Status Code Description

1xx: Informational

Communicates transfer protocol-level information.

2xx: Success

Indicates that the client’s request was accepted successfully.

3xx: Redirection

Indicates that the client must take some additional action in order to complete their request.

4xx: Client Error

Indicates that client request had some problem, which must be resolved on client side.

5xx: Server Error

The server takes responsibility for these error status codes.

Detailed error code description from REST perspective

200 (OK)

It is a generic HTTP response that indicates the REST API successfully carried out whatever action the client requested, and that no more specific code in the 2xx series is appropriate.

201 (CREATED)

A REST API responds with the 201 status code whenever a resource is created inside a collection. If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead.

202 (ACCEPTED)

A 202 response is typically used for actions that take a long while to process. It indicates that the request has been accepted for processing, but the processing has not been completed.

301 (Moved Permanently)

The 301 status code indicates that the REST API’s resource model has been significantly redesigned and a new permanent URI has been assigned to the client’s requested resource. The REST API should specify the new URI in the response’s Location header and all future requests should be directed to the given URI.

302 (Found)

The HTTP response status code 302 Found is a common way of performing URL redirection. An HTTP response with this status code will additionally provide a URL in the location header field. The user agent (e.g. a web browser) is invited by a response with this code to make a second, otherwise identical, request to the new URL specified in the location field.

304 (Not Modified)

304 is used when the resource has not been modified since the version specified by the request headers If-Modified-Since or If-None-Match.

400 (Bad Request)

400 is the generic client-side error status, used when no other 4xx error code is appropriate. Errors can be like malformed request syntax, invalid request message parameters, or deceptive request routing etc. The client SHOULD NOT repeat the request without modifications.

401 (Unauthorized)

A 401 error response indicates that the client tried to operate on a protected resource without providing the proper authorization. It may have provided the wrong credentials or none at all. The client MAY repeat the request with a suitable Authorization header field.

403 (Forbidden)

A 403 error response indicates that the client’s request is formed correctly, but the REST API refuses to honor it i.e. the user does not have the necessary permissions for the resource. A 403 response is not a case of insufficient client credentials; that would be 401 (“Unauthorized”). Authentication will not help and the request SHOULD NOT be repeated.

404 (Not Found)

The 404 error status code indicates that the REST API can’t map the client’s URI to a resource but may be available in the future. Subsequent requests by the client are permissible.

405 (Method Not Allowed)

The API responds with a 405 error to indicate that the client tried to use an HTTP method that the resource does not allow. For instance, a read-only resource could support only GET and HEAD, while a controller resource might allow GET and POST, but not PUT or DELETE.

410 (GONE)

The requested content no more exists and the request must not be retried. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval.

415 (Unsupported Media Type)

The 415 error response indicates that the API is not able to process the client’s supplied media type, as indicated by the Content-Type request header.

500 (Internal Server Error)

500 is the generic REST API error response. Most web frameworks automatically respond with this response status code whenever they execute some request handler code that raises an exception.

501 (Not Implemented)

The server either does not recognize the request method, or it lacks the ability to fulfill the request. Usually, this implies future availability (e.g., a new feature of a web-service API). So the request may be retried after some duration.

502 (Bad Gateway)

The server was acting as a gateway or proxy and received an invalid response from the upstream server.

503 (Service Unavailable)

The server cannot handle the request (because it is overloaded or down for maintenance). Generally, this is a temporary state.

504 (Gateway Timeout)

The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.


Top articles in this category:
  1. Top 50 SDET Java Programming Interview Questions & Answers
  2. Using h2load for REST API benchmarking
  3. Self signed HttpClient and RestTemplate for testing
  4. What is Idempotent Operation? What methods should be made idempotent?
  5. OAuth2 Login with Rest Assured Testcases
  6. OAuth2 protected resources using RestTemplate
  7. How to reverse a number in Java



Find more on this topic:
SDET Interviews image
SDET Interviews

End to end automation testing using Selenium Web Driver, Rest Assured, JMeter, Junit, TestNG etc.

Last updated 1 month ago


Recommended books for interview preparation:

This website uses cookies to ensure you get the best experience on our website. more info