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!