HTTP is defined through a series of Request for Comments (RFC) documents. We won't review all of the particulars, but we will touch on the three main points.

The HTTP protocol includes requests and replies. A request includes a method, a Uniform Resource Identifier (URI), some headers, and optional attachments. A number of available methods are defined in the standards. Most browsers focus on making GET and POST requests. The standard browsers include the GET, POST, PUT, and DELETE requests, which are the ones that we'll leverage, because they correspond to CRUD operations. We'll ignore most of the headers and focus on the path portion of the URI.

An HTTP reply includes a status code number and reason text, as well as any headers and attached data. There are a variety of status code numbers. The response codes are generally understood according to these patterns:

• The 1xx codes are informational, and not used widely in RESTful services.
• The 2xx replies indicate success.
• The 3xx status codes indicate the redirection of a request to a different host or a different URI path.
• The 4xx response codes tell the client that the request is erroneous, and the reply should include a more detailed error message.
• The 5xx codes generally mean that the server has had some kind of problem.

Of these general ranges, we're interested in just a few, as follows:

• The 200 status code is the generic OK response from a server.
• The 201 status code is the Created response, which might be used to show us that a POST request worked and an object was successfully created.
• The 204 status code is the No Content response, which might be used for a DELETE request. 
• The 400 status code is a Bad Request response, used to reject invalid data used to POST, PUT, or PATCH an object.
• The 401 status code is Unauthorized; this would be used in a secure environment to reject invalid credentials. It may also be used if valid user credentials are used, but the user lacks the authorization to take the action they requested.
• The 404 status code is Not Found, which is generally used when the URI path information does not identify a resource. 

HTTP is defined as stateless. The server is not expected to have any recollection of previous interactions with a client. In some cases, this is a profound limitation, and there are several commonly used workarounds to manage state by exchanging state details with the client of the transaction. For interactive websites, cookies are sent from the server to the client. The client embeds the cookies with the request to the server, allowing the server to recover the transaction state and offer rich, stateful application behavior.

Cookies are often used when a web server provides the user experience through HTML forms. By sending cookies back to the browser, a server can track user login and session information. As the user takes actions, the server records details in the session objects that are serialized as cookies. 

For RESTful web services, however, the client will not be a person sitting at a browser. The client of a RESTful service will be an application that can maintain the state of the user experience. This means that RESTful services can leverage simpler, stateless HTTP without cookies. This also means that states such as logged-in and logged-out don't apply to web services. For authentication purposes, credentials of some kind are often provided with each request. This imposes an obligation to secure the connection. In practice, all RESTful web servers will use a Secure Sockets Layer (SSL) and an HTTPS connection.

In the next section, we'll look at how to implement CRUD operations via REST.