Get Some REST: Server Responses

Last week I covered the basics of RESTful architecture on the client side. This week I'll be talking about the server side.

When a client sends a request to the server, content types are included in the request header. When the server is returning a data payload, it needs to include a content type in the header of its response.

A client trying to access a resource could look like this:

GET /posts/19 HTTP/1.1
Accept: application/json, text/html

And the server response might look something like this:

HTTP/1.1 200 (OK)
Content-Type: application/json

That brings us to response codes! When a server returns a response it includes a status code that lets the client know whether or not the request was successful. There are a lot of different status codes, too many to remember but here are the most common ones:

200 (OK) - Response to a successful HTTP request
201 (CREATED) - Response to an HTTP that successfully created an item.
204 (NO CONTENT) - Response to a successful HTTP request where nothing is being returned in the response.
400 (BAD REQUEST) - Response failed due to improper syntax, excessive size or some other error coming from the client side.
403 (FORBIDDEN) - The client doesn't have permission to access the resource.
404 (NOT FOUND) - The one most people see most frequently. This response says that the server wasn't able to find this resource.
500 (INTERNAL SERVER ERROR) - Blanket error for unexpected failures when more information isn't available.  

All HTTP verbs have an expected status code when the request is carried out successfully:

GET - 200 (OK)
POST - 201 (CREATED)
PATCH - 200 (OK)
DELETE - 204 (NO CONTENT)

and that concludes our high-level overview of REST!