API Testing Tutorial Part 7 – HTTP Status Code Must To Be Remembered

Hello Folks,

As part of our API Testing series, we will see some important HTTP status codes in this post. This topic is very important for API testing. It is a frequently asked interview question as well.

“Status” is what for everyone cares as it says what is output either negative or positive or partially.

When an HTTP request is hit, server returns status of that request as status line part of HTTP response. As per RFC-2616:

The first line of a Response message is the Status-Line, consisting of the protocol version followed by a numeric status code and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.

       Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request.The Reason-Phrase is intended to give a short textual description of the Status-Code.

Categorisation of HTTP codes:

HTTP codes are categorised based on class of response which is represented by first digit of status code.

a.  1xx: Informational - Request received, continuing process
b.  2xx: Success - The action was successfully received,
        understood, and accepted
c.  3xx: Redirection - Further action must be taken in order to
        complete the request
d.  4xx: Client Error - The request contains bad syntax or cannot
        be fulfilled
e.  5xx: Server Error - The server failed to fulfill an apparently
        valid request

Now we will see some status codes which we must know.

  1. 200 (OK) => All is GOOD. It is the most positive status code which everyone expects. This status code is thrown when requested operation on server by client is successfully processed.
  2. 201 (Created) ==> This status code is thrown when an HTTP method to hit to create a new resource on server and resource is created successfully. This status code makes more sense for HTTP methods which are meant to create new resources.
  3. 202(Accepted) ==> If a request is queued for processing or takes longer time to process, this status code is thrown to client. The request might or might not be eventually acted upon, or even maybe disallowed when processing occurs.
  4. 204 (No Content) ==> When a request is processed successfully but returns no state representation of resource to be included in the response message body, throws 204 status code. Its success without response body.
  5. 400 (Bad Request) ==> It is a client side error made when user submits inappropriate request like malformed request syntax, invalid request message parameters, or deceptive request routing etc. Client should correct request before hitting again.
  6. 401 (Unauthorised) ==> When a client submits a request with no or wrong authorisation on a resource which is protected by authorisation , this status code is thrown. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource.
  7. 403 (Forbidden) ==> When a user tries to access a resource on which user has no permission, this error will be thrown. It is not like 401. Request and proper authorization is provided in request body but user has no access on request resource.
  8. 404( Not Found) ==> If the request resource is not available at given URI or rest api can’t map the client’s URI to a resource, this status code is thrown.
  9. 405( Method Not Allowed) ==> When a client calls an HTTP method on a resource which is not applicable to on it, this status code is thrown. For example: If client hits a POST method on a GET resource, it will throw 405. Response includes  “Allow” header, which lists the HTTP methods that the resource supports.
  10. 406(Not Acceptable) ==> If API can not format data as per client’s provided media types in Accept request header, this status code is thrown.  For example, a client request for data formatted as application/xml will receive a 406 response if the API is only willing to format data as application/json.
  11. 415 (Media Type) ==> If API is not able to process the client’s supplied media type, as indicated by the Content-Type request header, this status code is thrown. It indicates that part of the request was in an unsupported format. For example, a client request including data formatted as application/xml will receive a 415 response if the API is only willing to process data formatted as application/json.
  12. 500 (Internal Server Error) ==> It is server side error. When server encounters an exception while processing a request, this status code is thrown. Please note here it is not client side error.
  13. 501 (Not Implemented) ==> When the server does not recognize the request method and is not capable of supporting it for any resource, this status code is thrown. The server either does not recognize the request method, or it lacks the ability to fulfill the request.

Above are most commonly HTTP status codes which you may encounter during API testing. You should remember meaning of these status codes. For deeper understanding, you can refer below links:

HTTP statuses 

HTTP codes in Rest API

More about API Testing in upcoming posts. Stay tuned.

If you have any doubt, feel free to comment below.
If you like my posts, please like, comment, share and subscribe.
#ThanksForReading
#HappyApiTesting

5 thoughts on “API Testing Tutorial Part 7 – HTTP Status Code Must To Be Remembered

Leave a Reply to Gaurav Khurana Cancel reply

Your email address will not be published. Required fields are marked *