Home » Software Development » Common HTTP Status codes

About Michael Scharhag

Michael Scharhag
Michael Scharhag is a Java Developer, Blogger and technology enthusiast. Particularly interested in Java related technologies including Java EE, Spring, Groovy and Grails.

Common HTTP Status codes

What is a HTTP status code?

HTTP status codes are part of the status-line of a HTTP response. These 3-digit integer codes indicate the result of the servers attempt to satisfy the request.

The first digit of the status-code is used to categorize the response:

  • 1xx: Informal
  • 2xx: Success, the request has been understood and accepted
  • 3xx: Redirection, further action needs to be taken
  • 4xx: Client error, there was a problem with the request
  • 5xx: Server error, the request has been accepted, but the processing failed due to a server error

Commonly used HTTP status codes

Here is a list of status codes commonly used in web applications and REST APIs.

HTTP 200 OK

The request has succeeded. HTTP 200 is often used as the default status code to indicate that everything worked as expected. However, other 2xx status code can be more specific in certain situations.

HTTP 201 Created

The request has succeeded and a new resource has been created. HTTP 201 is often used after a resource has been created by a POST or PUT request (see REST: Creating resources). The Location header field can be used to return the URI(s) of the newly created resource. Note that the resource must be created before 201 is returned. If the resource is created later by an asynchronous process, the server should respond with HTTP 202 (Accepted, see below).

HTTP 202 Accepted

The request has been accepted, but the processing has not been completed. For example, the server might have saved the request, but the processing will be done later by a batch job. It is also possible that the request might be disallowed when processing actually takes place. In this case, the request has no effect. The response should include some indication about the processing status. It can also be a good idea to return a reference to a resource where the client can get the current processing status and the result once processing has been finished.

HTTP 204 No Content

The request succeeded, but there is no content to send for this request. When sending 204 the response body must be empty. Updated meta-information can be passed in response headers.

HTTP 304 Not Modified

This status code is used for caching purposes when a client issued a conditional GET request. Such a request has to contain a If-None-Match or If-Modified-Since header. 304 is returned with an empty response body to indicate that the resource has not been modified. In case the resource has been modified, the resource should be returned with a status code 200 (OK).

HTTP 307 Temporary Redirect

The URI of the target resource has been temporary changed and current URI is given in the response Location header. Temporary Redirect indicates that the client should use the original request URI for future requests.

HTTP 308 Permanent Redirect

Like 307 this status code is used when the target resource URI has been changed. The new URI is again given in the Location header. However, 308 indicates that the URI change is permanent and clients should use the updated URI for future requests.

HTTP 400 Bad Request

The request has been received, but the server is unable to process it due to malformed request syntax. The client should not repeat the request without modification. This status code is often returned if server side validation of the request data fails.

HTTP 401 Unauthorized

The request lacks credentials and cannot be authenticated. Note that this status code is badly named, it is used to indicate missing authentication not missing authorization. For missing authorization HTPP 403 is used. This status code is typically returned if the request does not include required authentication information such as passwords or tokens.

HTTP 403 Forbidden

The client is authenticated, but does not have the permission to use the given request method on the requested resource. It is also viable to respond with HTTP 404 (Not Found) in these situations if the server wants to hide the resource. The client should not repeat the request (without changing credentials). If the client is not authenticated at all, HTTP 401 should be returned instead.

HTTP 404 Not Found

The server has not found the requested URI and is therefore unable to process the request.

HTTP 405 Method Not Allowed

The server does not allow the requested HTTP method for the given URI. For example, the request specifies the PUT method for a resource that only supports GET and POST. The response must include an Allow header containing a list of valid request methods for the requested resource.

HTTP 409 Conflict

The request could not be completed due to a conflict with the current state of the resource. This code must only be used in situations where the user might be able to resolve the conflict and reissue the request. The response body should contain information about the conflict so the client is able to solve it. An example can be a resource update using PUT. Maybe the resource has been updated by another third-party request and the current request does not reflect the current resource state.

HTTP 500 Internal Server Error

The server has encountered a situation it is unable to handle. This is the standard status code for unexpected error on the server during the request processing.

Published on Java Code Geeks with permission by Michael Scharhag, partner at our JCG program. See the original article here: Common HTTP Status codes

Opinions expressed by Java Code Geeks contributors are their own.

(0 rating, 0 votes)
You need to be a registered member to rate this.
Start the discussion Views Tweet it!
Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
I agree to the Terms and Privacy Policy
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments