That’s right, since we know HTTP is going to play a key role with REST APIs, let’s review the fundamentals of this important protocol.
In our DevNet Associate training here at Lammle.com, we talk a lot about how HTTP is ideal for RESTful API usage because of its simple, yet effective, request/response cycle (as it is called). A client makes a simple request of a server, which in turn responds to the request.
But how do we make a request from that remote server? What are the elements required to do this in a Web browser? It turns out, there are four major components we use to do accomplish this:
- Uniform Resource Locator (URL) – this is the term for the complete syntax we enter in the Web broswer. It can consist of four different parts (of which several are mandatory). You have the protocol (HTTP/HTTPS); the server address (either a name or an IP address); the resource location; and optional parameters.
- The HTTP method in use – options here are GET, PUT, DELETE, CONNECT, HEAD, POST, PATCH, TRACE, OPTIONS; remember these options are ideal for carrying out the CRUD actions required by most applications. For example, the GET method is ideal for the READ verb of CRUD.
- A list of headers
- The body of the message
A very common example of an HTTP request is a GET request. Think how powerful the GET has been for the Internet as we know it today. This HTTP method the retrieval of Web pages and the images included in these pages.
What is included in this GET request when it is sent to the server? The keyword GET must be all uppercase. A Request URI specifies the path of the resource requested, which must begin from the root / of the document base directory.
The HTTP version is also communicated in the GET request. It is either HTTP/1.0 or HTTP/1.1.
Optionally, your GET request can include request headers. The client can use optional request headers (such as accept and accept language) to negotiate with the server and ask the server to deliver the preferred contents (such as in the language the client).
A GET request message has an optional request body, which contains the query string.
So we can clearly see that the HTTP GET must contain specific parameters in order to receive the correct (and desired) Web (or other) content. This is the same approach when we examine the popular POST HTTP method. While the intent of this method is to send data to the server, once again, it is the request/response cycle that is used, and once again, the messaging that is sent to the server must contain certain elements and may contain others.
Let’s wrap up this post by taking a look at one of those optional response headers:
Accept: image/gif, image/jpeg, */*
Accept-Language: us-en, fr, cn