The 2xx error codes indicate that an operation was successful.
Importance: Very high.
In most cases, this is the code the client hopes to see. It indicates that the server successfully carried out whatever action the client requested, and that no more specific code in the 2xx series is appropriate. My bookmarking service sends this code, along with a representation, when the client requests a list of bookmarks.
Entity-body: For GET requests, a representation of the resource the client requested. For other requests, a representation of the current state of the selected resource, or a description of the action just performed.
The server sends this status code when it creates a new resource at the client’s request. My bookmarking service sends this code in response to a POST request that creates a new user account or bookmark.
Response headers: The
Location header should contain the canonical
URI to the new resource.
Entity-body: Should describe and link to
the newly created resource. A representation of that resource is
acceptable, if you use the
header to tell the client where the resource actually lives.
This is an appropriate response when a request triggers an asynchronous action, an action in the real world, or an action that would take so long that there’s no point making the web client wait around. It’s an important part of the RESTful system for asynchronous operations that I described in Chapter 8.
Response headers: The pending request
should be exposed as a resource so the client can check up on it
Location header can
contain the URI to this resource.
Entity-body: If there’s no way for the client to check up on the request later, at least give an estimate of when the request will be processed.
Importance: Very low.
This status code is the same as 200 (“OK”), but the server wants the client to know that some of the response headers do not come from the server. They may be mirrored from a previous request of the client’s, or obtained from a third party.
Response Headers: The client should know that some headers may not be accurate, and others may be passed along without the server knowing what they mean.
This status code is usually sent out in response to a PUT, POST, or DELETE request, when the server declines to send back any status message or representation. The server may also send 204 in conjunction with a GET request: the resource requested exists, but has an empty representation. Compare 304 (“Not Modified”).
204 is often used in Ajax applications. It lets the server tell the client that its input was accepted, but that the client shouldn’t change any UI elements.
Entity-body: Not allowed.
This is just like 204 (“No Content”), but it implies that the client should reset the view or data structure that was the source of the data. If you submit an HTML form in your web browser and the response is 204 (“No Content”), your data stays in the form and you can change it. If you get a 205, the form fields reset to their original values. In data entry terms: 204 is good for making a series of edits to a single record; 205 is good for entering a series of records in succession.
Entity-body: Not allowed.
Importance: Very high for services that support partial GET, low otherwise.
This is just like 200 (“OK”), but it designates a response to a partial
GET request: that is, one that uses the
Content-Range request header. A client
usually makes a partial GET request to resume an interrupted download
of a large binary representation. I cover partial GET in Chapter 8.
Request headers: The client sends a value
Response headers: The
Date header is required. The
Content-Location headers should be set to
the same values that would have been sent along with the
representation as a whole.
If the entity-body is a single byte range from the
representation, the response as a whole must have a
Content-Range header explaining which bytes
of the representation are being served. If the body is a multipart
entity (that is, multiple byte ranges of the representation are being
served), each part must have its own
Entity-body: Will not contain a full representation: just one or more sequences of bytes from the representation.
Importance: Low to medium.
This is a WebDAV extension to the HTTP standard which is useful in the response to a batch request. I showed a RESTful way of exposing batch operations in Chapter 8, and I pointed out that when a request operates on more than one resource, some operations might succeed while others fail. A single response code won’t suffice to convey the status of the request.
This response code tells the client to look in the entity-body for a list of HTTP status codes: one for each operation in the batch request. This violates the principle that the client should be able to figure out what happened to the request just by looking at the first three bytes, but when a single request carries out more than one operation, there’s no alternative.
Entity-body: Should contain an XML document that uses the WebDAV vocabulary to describe a number of HTTP responses. The WebDAV standard (RFC 2518) defines this XML vocabulary and gives several examples.