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
Types of Rest Requests
Best practices
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 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.
Put Vs Post
Useful links:
What is the use of Accept and Content-Type Headers in HTTP Request? Accept headers tells web service what kind of response client is accepting, so if a web service is capable of sending response in XML and JSON format and client sends Accept header as application/xml then XML response will be sent. For Accept header application/json, server will send the JSON response
Content-Type header is used to tell server what is the format of data being sent in the request. If Content-Type header is application/xml then server will try to parse it as XML data. This header is useful in HTTP Post and Put requests.
Comments