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.
What You Will Learn:
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.
|GET||Fetch status line, Response body, Header etc.|
|HEAD||Same as GET, but only fetch status line and header section|
|POST||Perform request using request payload mostly in creating a record at the server|
|PUT||Useful in manipulating/updating the resource using Request payload|
|DELETE||Deletes information relating to the target resource.|
|OPTIONS||Describe the communication options for the target resource|
|PATCH||Very much similar to put but it is more like a minor manipulation of resource content|
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.
Request URI: http://jsonplaceholder.typicode.com/posts
Query Parameter: id=3;
Response Status Code: 200 OK
Request URI: http://jsonplaceholder.typicode.com/posts
Request URI: http://jsonplaceholder.typicode.com/
Headers: Content-type = Application/JSON
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-
Additional parameter at the end of the URL
Enabling the user to specify, select the desired data instead of providing them all at a time.
/contact/sam?name, age, designation, office
Timestamp in each and every API Request and Response. Use of access_token to make sure that API is invoked by the trust parties.
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.
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 10th 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.
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.