HTTP Status Codes

• In this section lets describe how and when to use the subset of codes that apply to REST API design
• Rule: 200 (“OK”) should include a response body
• Rule: 200 (“OK”) must not be used to communicate errors in response body
• Rule: 201 (“Created”) must be used to indicated successful resource creation
• Rule: 202 (“Accepted”) must be used to indicate successful start of asynchronous action.

• Rule: 204 (“No Content”) should be used when the response body is intentionaly empty

• Rule: 301 (“Moved Permanently”) should be used to relocate resources

• Rule: 302 (“Found”) should not be used
• Rule: 303 (“See Other”) should be used to refer the client to a different URI
• Rule: 304 (“Not Modified”) should be used to preserve bandwidth

• Rule: 307 (“Temporary Redirect”) should be used to tell clients to resubmit the request to another URI

• Rule: 400 (“Bad Request”) may be used to indicated nonspecific failure

• Rule: 401 (“Unauthorized”) must be use when there is problem with client credentials
• Rule: 403 (“Forbidden”) should be used to forbid the access regardless of authorization state.
• Rule: 404 (“Not Found”) must be used when a client’s URI cannot be mapped to a Resource.
• Rule: 405 (“Method Not Allowed”) must be used when the HTTP method is not supported
• Rule: 406 (“Not Acceptable”) must be used when the requested media type is not served.
• Rule: 412 (“Precondition failed”) should be used to support conditional operations

• Rule: 414 (“Unsupported Media type”) must be used when the media type of the requests payload cannot be processed

• Rule: 500 (“Internal Server Error”) should be used to indicate the API Malfunction

• Refer Here for the complete list of HTTP Status Codes.

Lets Start using PostMan For some API Testing

• Lets Create a Collection and Call it as Learning APIs
  
  
  
• Lets test the BooksAPI Refer Here
  
  
  
• Search for a book