Success Codes
The 200 series of response codes indicate success.200 This is your basic "everything is honkey dorey" response.
201 - Created This response tells the client that in response to their request, a resource was created. The location header should contain the address of this new resource, while the body of the response should either be a representation of the new resource, or a document describing the new resources location.
202 - Accepted This response indicates that everything looks good as far as the client's request, but the request will not be processed in real-time, so errors could further down the line.
203 - Non Authoritative Info This indicates that everything looks good, but this is information being passed from another resource, so there is no way of telling if all of the information contained in the headers is accurate.
204 - No Content This indicates that a request has been sent to the server, but the server, without error, has declined to send a response. This is useful for Asynchronous applications where you want to tell the client that everything is fine and not to change any UI elements.
205 - Reset Content This is a 204, coupled with the additional instruction of resetting any dynamic form elements. From a simple database centric perspective, a 204 would be useful for continually editing a single record. A 205 would be useful for creating several records in succession.
206 - Partial Content This is a success response for a large, multi-part request, indicating that you are currently sending a range of data. This implies the use of the content-range header which should indicate the range in bytes of the document being served.
Real World Usage
In the wild it seems that 99% of the response codes I see are either 200, 404, 301, or 302. That makes sense for basic web pages.One of the reasons to utilize the standards is universal compatibility. You might be thinking web app today, but next year somebody might be interested in creating a thick client for your application or integrating a client into a handheld device. The more you utilize the protocol standard - as opposed to building everything at the client level - the better your chances for cross-platform compatibility.
Of course, there are more than a few instances of scripts out there that specifically seek out a 200 response rather than a successful response. That's a problem with their code, not yours. Stick with the standards and teach them to others and the world will be a better place.
Talk About HTTP Success Codes You Should Know About
