Web applications are a common thing in our lives, and they are usually very user friendly; users do not need to understand how they work behind the scenes. As a developer, though, you need to understand how your application works internally.
In this chapter, you will learn about:
- HTTP and how web applications make use of it
- Web applications and how to build a simple one
- Web servers and how to launch your PHP built-in web server
If you check the RFC2068 standard at https://tools.ietf.org/html/rfc2068, you will see that its description is almost endless. Luckily, what you need to know about this protocol, at least for starters, is way shorter.
HTTP stands for HyperText Transfer Protocol. As any other protocol, the goal is to allow two entities or nodes to communicate with each other. In order to achieve this, the messages need to be formatted in a way that they both understand, and the entities must follow some pre-established rules.
The following diagram shows a very basic interchange of messages:
A simple GET request
Do not worry if you do not understand all the elements in this diagram; we will describe them shortly. In this representation, there are two entities: sender and receiver. The sender sends a message to the receiver. This message, which starts the communication, is called the request. In this case, the message is a GET request. The receiver receives the message, processes it, and generates a second message: the response. In this case, the response shows a 200 status code, meaning that the request was processed successfully.
HTTP is stateless; that is, it treats each request independently, unrelated to any previous one. This means that with this request and response sequence, the communication is finished. Any new requests will not be aware of this specific interchange of messages.
An HTTP message contains several parts. We will define only the most important of them.
The URL of the message is the destination of the message. The request will contain the receiver's URL, and the response will contain the sender's.
As you might know, the URL can contain extra parameters, known as a query string. This is used when the sender wants to add extra data. For example, consider this URL: http://myserver.com/greeting?name=Alex. This URL contains one parameter: name with the value Alex. It could not be represented as part of the URL http://myserver.com/greeting, so the sender chose to add it at the end of it. You will see later that this is not the only way that we can add extra information into a message.
The HTTP method is the verb of the message. It identifies what kind of action the sender wants to perform with this message. The most common ones are GET and POST.
- GET: This asks the receiver about something, and the receiver usually sends this information back. The most common example is asking for a web page, where the receiver will respond with the HTML code of the requested page.
- POST: This means that the sender wants to perform an action that will update the data that the receiver is holding. For example, the sender can ask the receiver to update his profile name.
There are other methods, such as PUT, DELETE, or OPTION, but they are less used in web development, although they play a crucial role in REST APIs, which will be explained in Chapter 9, Building REST APIs.
The body part is usually present in response messages even though a request message can contain it too. The body of the message contains the content of the message itself; for example, if the user requested a web page, the body of the response would consist of the HTML code that represents this page.
Soon, we will discuss how the request can also contain a body, which is used to send extra information as part of the request, such as form parameters.
The body can contain text in any format; it can be an HTML text that represents a web page, plain text, the content of an image, JSON, and so on.
The headers on an HTTP message are the metadata that the receiver needs in order to understand the content of the message. There are a lot of headers, and you will see some of them in this book.
Headers consist of a map of key-value pairs. The following could be the headers of a request:
Accept: text/html Cookie: name=Richard
This request tells the receiver, which is a server, that it will accept text as HTML, which is the common way of representing a web page; and that it has a cookie named Richard.
The status code is present in responses. It identifies the status of the request with a numeric code so that browsers and other tools know how to react. For example, if we try to access a URL that does not exist, the server should reply with a status code 404. In this way, the browser knows what happened without even looking at the content of the response.
Common status codes are:
The following diagram shows a POST request and its response:
A more complex POST request
In this exchange of messages, we can see the other important method, POST, in action. In this case, the sender tries to send a request in order to update some entity's data. The message contains a cookie ID with the value 84, which may identify the entity to update. It also contains two parameters in the body: name and age. This is the data that the receiver has to update.
The response has a status code of 200, meaning that the request was processed successfully. In addition, the response also contains a body, this time formatted as JSON, which represents the new status of the updated entity.