Rest API Response Codes And Types Of Rest Requests

In This Tutorial, we will Learn About Different REST Response Codes, Types of REST Requests, and Some Best Practices to be Followed:

In the previous tutorial, REST API Architecture And Constraints, we have learned about web services, REST Architecture, POSTMAN, etc.

We may refer to the REST API first tutorial for more information on this.

Whenever you search any word or phrase in a search engine, the search engine sends the request to the webserver. The web server returns a three-digit response code which indicates the status of the request.

Rest API Response Codes

Here are some sample Response Codes which we will normally see while performing REST API testing over POSTMAN or over any REST API client.

#1) 100 Series
These are temporary Responses

• 100 Continue
• 101 Switching Protocols
• 102 Processing

#2) 200 Series
The client accepts the Request, being processed successfully at the server.

• 200 – OK
• 201 – Created
• 202 – Accepted
• 203 – Non-Authoritative Information
• 204 – No Content
• 205 – Reset Content
• 206 – Partial Content
• 207 – Multi-Status
• 208 – Already Reported
• 226 – IM Used

#3) 300 Series
Most of the codes related to this series are for URL Redirection.

• 300 – Multiple Choices
• 301 – Moved Permanently
• 302 – Found
• 303 – Check Other
• 304 – Not Modified
• 305 – Use Proxy
• 306 – Switch Proxy
• 307 – Temporary Redirect
• 308 – Permanent Redirect

#4) 400 Series
These are specific to client-side error.

• 400 – Bad Request
• 401 – Unauthorised
• 402 – Payment Required
• 403 – Forbidden
• 404 – Not Found
• 405 – Method Not Allowed
• 406 – Not Acceptable
• 407 – Proxy Authentication Required
• 408 – Request Timeout
• 409 – Conflict
• 410 – Gone
• 411 – Length Required
• 412 – Precondition Failed
• 413 – Payload Too Large
• 414 – URI Too Long
• 415 – Unsupported Media Type
• 416 – Range Not Satisfiable
• 417 – Expectation Failed
• 418 – I’m a teapot
• 421 – Misdirected Request
• 422 – Unprocessable Entity
• 423 – Locked
• 424 – Failed Dependency
• 426 – Upgrade Required
• 428 – Precondition Required
• 429 – Too Many Requests
• 431 – Request Header Fields Too Large
• 451 – Unavailable For Legal Reasons

#5) 500 Series
These are specific to the server-side error.

• 500 – Internal Server Error
• 501 – Not Implemented
• 502 – Bad Gateway
• 503 – Service Unavailable
• 504 – Gateway Timeout
• 505 – HTTP Version Not Supported
• 506 – Variant Also Negotiates
• 507 – Insufficient Storage
• 508 – Loop Detected
• 510 – Not Extended
• 511 –  Network Authentication Required

Apart from this, there are several different codes that exist but those will deviate us from our current discussion.

Different Type Of REST Requests

Here we will discuss each and every method of REST API along with the collections.

Note: There are so many methods that exist, which we can do using POSTMAN but we will be discussing only the following methods using POSTMAN.

We shall use a dummy URL to demonstrate  http://jsonplaceholder.typicode.com. This URL shall give us the desired responses but there will not be any creation, modification in the server.

#1) GET

Request Parameters:
Method: GET
Request URI: http://jsonplaceholder.typicode.com/posts
Query Parameter: id=3;

Response Received:
Response Status Code: 200 OK

Response body:

#2) HEAD

Request Parameters:
Method: HEAD
Request URI: http://jsonplaceholder.typicode.com/posts

#3) POST

#4) PUT

#5) OPTIONS

Request Parameters:
Method: OPTIONS
Request URI: http://jsonplaceholder.typicode.com/
Headers: Content-type = Application/JSON

#6) PATCH

Best Practices While Validating A REST API

#1) CRUD Operations

Consist of minimum 4 methods provided and should be working in the Web API.
GET, POST, PUT and DELETE.

#2) Error Handling

Possible hints for the API consumers about the error and why it has occurred. It also should provide granular level error messages.

#3) API Versioning

Use the letter ‘v’ in the URL to denote the API version. For example-

http://restapi.com/api/v3/passed/319

Additional parameter at the end of the URL

http://restapi.com/api/user/invaiiduser?v=6.0

#4) Filtering

Enabling the user to specify, select the desired data instead of providing them all at a time.
/contact/sam?name, age, designation, office
/contacts?limit=25&offset=20

#5) Security

Timestamp in each and every API Request and Response. Use of access_token to make sure that API is invoked by the trust parties.

#6) Analytics

Having Analytics in your REST API will give you a good insight of API under test especially when the number of records fetched is very high.

#7) Documentation

Proper documentation is to be provided so that API consumers can use it and consume the services effectively.

#8) URL Structure

URL structure should remain simple and a user should be able to read the domain name easily over it.

For Example, https://api.testdomain.com.

Operations to be performed over the Rest API should also be very easy to understand and perform.

For Example, for an Email client:

GET: read/inbox/messages – Retrieves the list of all message under inbox
GET: read/inbox/messages/10 – Reads 10^th message in inbox
POST: create/inbox/folders – Create a new folder under inbox
DELETE: Delete/spam/messages – Delete  all the messages under spam folder
PUT: folders/inbox/subfolder – Update the information relating to the subfolder under inbox.

Conclusion

Many organizations prefer to implement REST Web API since it is very easy to implement, has lesser standards and rules to follow, easy to access, lightweight, and easy to understand. POSTMAN has its advantages when used with RESTful API due to its user-friendly UI, ease of use and test, faster response rate and new RUNNER feature.

In the next tutorial in this Rest API Tutorial series, we will automate the test cases which we have executed manually.