HTTP STATUS CODES
The list of http status codes are listed here and also in RFC 7230. However, the status codes do not define the error response when things go wrong. The error response format is defined in RFC 7807 .
Overall the status codes are in the range of 1xx-5xx & are divided into below 5 classes with first digit signifying the class of response.
- 1xx Informational response
- 2xx Success
- 3xx Redirection
- 4xx Client errors
- 5xx Server errors
The following codes are not specified by any standard.
- 103 Checkpoint
- Used in the resumable requests proposal to resume aborted PUT or POST requests.
- 218 This is fine (Apache Web Server)
- Used as a catch-all error condition for allowing response bodies to flow through Apache when ProxyErrorOverride is enabled. When ProxyErrorOverride is enabled in Apache, response bodies that contain a status code of 4xx or 5xx are automatically discarded by Apache in favor of a generic response or a custom response specified by the ErrorDocument directive.
- 419 Page Expired (Laravel Framework)
- Used by the Laravel Framework when a CSRF Token is missing or expired.
- 420 Method Failure (Spring Framework)
- A deprecated response used by the Spring Framework when a method has failed.
- 420 Enhance Your Calm (Twitter)
- Returned by version 1 of the Twitter Search and Trends API when the client is being rate limited; versions 1.1 and later use the 429 Too Many Requests response code instead.
- 430 Request Header Fields Too Large (Shopify)
- Used by Shopify, instead of the 429 Too Many Requests response code, when too many URLs are requested within a certain time frame.
- 450 Blocked by Windows Parental Controls (Microsoft)
- The Microsoft extension code indicated when Windows Parental Controls are turned on and are blocking access to the requested webpage.
- 498 Invalid Token (Esri)
- Returned by ArcGIS for Server. Code 498 indicates an expired or otherwise invalid token.
- 499 Token Required (Esri)
- Returned by ArcGIS for Server. Code 499 indicates that a token is required but was not submitted.
- 509 Bandwidth Limit Exceeded (Apache Web Server/cPanel)
- The server has exceeded the bandwidth specified by the server administrator; this is often used by shared hosting providers to limit the bandwidth of customers.[79]
- 526 Invalid SSL Certificate
- Used by Cloudflare and Cloud Foundry's gorouter to indicate failure to validate the SSL/TLS certificate that the origin server presented.
- 529 Site is overloaded
- Used by Qualys in the SSLLabs server testing API to signal that the site can't process the request.
- 530 Site is frozen
- Used by the Pantheon web platform to indicate a site that has been frozen due to inactivity.
- 598 (Informal convention) Network read timeout error
- Used by some HTTP proxies to signal a network read timeout behind the proxy to a client in front of the proxy.
Internet Information Services
- 440 Login Time-out
- 449 Retry With
- 451 Redirect
- 444 No Response
- 494 Request header too large
- 495 SSL Certificate Error
- 496 SSL Certificate Required
- 497 HTTP Request Sent to HTTPS Port
- 499 Client Closed Request
Cloudflare
- 520 Web Server Returned an Unknown Error
- 521 Web Server Is Down
- 522 Connection Timed Out
- 523 Origin Is Unreachable
- 524 A Timeout Occurred
- 525 SSL Handshake Failed
- 526 Invalid SSL Certificate
- 527 Railgun Error
- 530
AWS Elastic Load Balancer
- 460 - Client closed the connection with the load balancer before the idle timeout period elapsed. Typically when client timeout is sooner than the Elastic Load Balancer's timeout.
- 463 - The load balancer received an X-Forwarded-For request header with more than 30 IP addresses.
HTTP Methods
- GET
- POST
- PUT
- DELETE
- HEAD
- PATCH
- OPTIONS
GET requests are used to retrieve data from an API server at the specified resource. A successful/valid GET request will return a response with status code 200.
POST requests are used to send data from an API server to create or update a resource. A successful/valid POST request will return a response with status code 201.
PUT requests are used to send data to the API to create or update a resource. The difference is that PUT requests are idempotent i.e. calling the same PUT request multiple times will always produce the same result.
In contrast, calling a POST request repeatedly may have side effects of creating the same resource multiple times. A successful/valid POST request will return a response with status code 200.
DELETE request deletes the resource at the specified URL. A successful/valid DELETE request will return a response with status code 200. A DELETE request where the specified resource is already deleted or non-existent will return a status code of 404 and a DELETE request to an unknown resource/specified URL will return a non-200 status code.
HEAD requests are same as GET but don't return the response body. For e.g if GET requests returns a list of names in the response body then HEAD request will make the same request but won't return the list of names. HEAD request is generally useful in confirming if a GET request will attempt to retrieve data successfully like before downloading a large file or a response body.
It's important to note that not every endpoint that support GET will support HEAD. This completely depends on the API you're testing.
POST requests are used to send data from an API server to create or update a resource. A successful/valid POST request will return a response with status code 201.
In contrast, calling a POST request repeatedly may have side effects of creating the same resource multiple times. A successful/valid POST request will return a response with status code 200.
HEAD requests are same as GET but don't return the response body. For e.g if GET requests returns a list of names in the response body then HEAD request will make the same request but won't return the list of names. HEAD request is generally useful in confirming if a GET request will attempt to retrieve data successfully like before downloading a large file or a response body.
It's important to note that not every endpoint that support GET will support HEAD. This completely depends on the API you're testing.
PATCH applies only partial modifications to the resource. The difference between PATCH and PUT, is that a PATCH request is non-idempotent (like a POST request).
With a PATCH request, you may only need to send the updated username in the request body - as opposed to POST and PUT which require the full user entity.
OPTIONS request returns data describing what other methods & operations the server supports at the given URL. OPTIONS requests are more loosely defined & used than the others, making them a good candidate to test for fatal API errors. If an API isn't expecting an OPTIONS request, it's good to put a test case in place that verifies failing behavior.
With a PATCH request, you may only need to send the updated username in the request body - as opposed to POST and PUT which require the full user entity.
OPTIONS request returns data describing what other methods & operations the server supports at the given URL. OPTIONS requests are more loosely defined & used than the others, making them a good candidate to test for fatal API errors. If an API isn't expecting an OPTIONS request, it's good to put a test case in place that verifies failing behavior.
