First Entry Network series notes (4) HTTP requests and responses

First, the reference note, this blog post for reference to the following

1.starok,http must know, http://www.cnblogs.com/starstone/p/4890409.html

2.careyson,http Agreement on the discussion, http://www.cnblogs.com/CareySon/archive/2012/04/27/HTTP-Protocol.html

3. The cold, analysis of the HTTP protocol, http://www.cnblogs.com/gpcuster/archive/2009/05/25/1488749.html

4.chance_yin,http http request, http://www.cnblogs.com/yin-jingyu/archive/2011/08/01/2123548.html

Second, HTTP request

• Format of the request message

An HTTP request message is also divided into three parts:

1. Request Line

2. Request the head

3. Request Body

where the request header format we have seen. The basic format of the request line is:

Method Path Version

For example, the following example:

GET/simple.html http/1.1

There is a correspondence relationship:

• Method: GET
• Path:/simple.html
• Version: http/1.1

The request line is the most basic element of the HTTP request message. Version is used to declare the HTTP message parsing rules, different versions in some places the performance is different, there is no too much disassembly. Now the latest version of the HTTP protocol in practice is http/1.1. The path can be interpreted as the entry of the request message to the server, and in general, the same path should represent the same resource entity. Method represents an action on the resource entity, such as the Get method described above, which means that the content of the resource is requested to be fetched. These are the usual explanations, but not necessarily the requirements. In fact, the server resolves to the method and path, making its own corresponding response based on the method and path. The rules of this response can be followed by certain specifications, or they can be completely regardless of the specifications that are arbitrary. There are already some conventions on the market, such as Restful. RESTful is a very good Web API design concept based on HTTP protocol, it's worth saying, but not here.

• Method

First, list the most common HTTP methods:

1.GET

2.POST

3.PUT

4.PATCH

5.DELETE

6.HEAD

7.OPTIONS

As previously mentioned, the server for the processing of methods, there is no mandatory specification. That's not all right. In fact, each HTTP method, there are some HTTP protocol requirements. For example, the Get method requested resources, the browser will generally have a cache, the next time the request may be taken from the cache is enough, the server does not have to send the same resources repeatedly, but the server if the method of acquiring the interface of the resource is defined as post, then the browser side will no longer cache the resources, Even if each fetch is the same content, the server is requested to resend it again. Therefore, it is an unreasonable design to define the method of requesting the interface of the resource as post instead of get.

For example, the Get method request message cannot define the body of the message, the head method's request whose response message is not the body of the message, these are the HTTP protocol for the HTTP method constraints.

• Path

The combination of methods and paths forms the gateway to the Web API, and the path is critical. The basic format of a path is generally:

　　basic-path[?query-string]

The contents of [] are optional. In the example above, Basic-path is/simple.html, but does not contain query-string content. The Basic-path form is much like the absolute path style in Unix, with A/head. Individual/Represents a path,/A,/a/b,/a/b/c are reasonable path representations. It is not recommended to use/a/,/a/b/,/a/b/c/, or any other form of content (except). Good API designers use different path hierarchies to organize resources reasonably.

The part behind the question mark is query-string. Its format is arbitrary, as long as the client and the server contract a certain form. This section is typically attached to the request parameter. As previously mentioned, the Get method does not contain the request body, so the HTTP request of the Get method wants to attach the parameter only in this way. Of course other methods can also be used this way to attach parameters, as long as the server agrees on it. The format of the query-string is arbitrary, but there is also a predetermined convention between the client and the server, which is the form of a key-value pair. Query-string can be represented as a collection of key-value pairs, expressed in the following ways:

　　k1=v1&k2=v2&k3=&k4

Here,& separates different key-value pairs, = represents the key and is worth the relationship. You can see a total of four key-value pair relationships, which are:

• K1:v1
• K2:v2
• K3: Empty string
• K4: At least the key is defined.

In general, key-value pairs are written in k=v form, but k= and only a k are allowed, which means that the value of key K is an empty string, which means that key k is defined, but its value is not concerned.

From the above example, it is found that in query-string & and = are used for special purposes, we can no longer use these two symbols in a leisurely manner. What if we want to include the two symbols in the value? The way is, coding .

In the actual HTTP request, for the following key-value relationship

　　k1: &

　　k2: =

The specific query-string to be written:

　　k1=%26&k2=%3D

This is because the 16-binary representation of the,& in ASCII encoding is the 16-binary representation of the 26,= is 3D. The required encoding is expressed as a 16-binary representation of its actual encoding, with each byte represented by a%xx of three characters. In this way, the% itself will be encoded, and its encoding is%25. In addition to the encoding of these control characters, it is possible to encode non-English languages such as Chinese.

For the coding section, I recommend a blog post for Nanyi.

　　About URL encoding

Although it may not be understood, but at least know that coding is not a simple thing.

• Request Header

The HTTP request header format is no different than the previous message header format, which is a colon-delimited pair of key values. The HTTP request header contains both pre-defined headers (such as Content-type, Content-length, and so on), as well as custom headers. Originally intended to list several common request headers, but limited to energy, not intended to do so. I'll just talk about my most used Content-type head.

The Content-type header, which can be used either for request messages or for response messages, is the header that specifies the format of the request body content. For example, using this header, we can specify that the text format is plain text format, form format, XML format, JSON format, image format, etc. For example, Content-type:application/json represents the JSON text format.

At the end of the section, I have a conscience to give a reference to the HTTP pre-defined header:

　　HTTP message Header Daquan

Third, HTTP response

The basic format of the HTTP response message is the same, with three parts:

1. Response lines

2. Response Head

3. Response body

Response header and response body I don't think I need to say any more. The basic format of the response line is:

　　版本号 状态码 状态文本

For example, the following response line:

　　HTTP/1.1 200 OK

The corresponding relationship is:

• Version number: http/1.1
• Status code: 200
• Status text: OK

The HTTP status code mainly indicates the state of the reply. The status code is represented by 3 numbers, where the first number represents a large state, and the next two digits represent a sub-state of the large state. 200 indicates successful operation, there are other common such as 404 indicates that the object is not found, 500 indicates a server error, 403 indicates that the directory cannot be browsed, and so on.

The status codes are divided into five large states, which are:

• 1xx
• 2XX: Request Successful processing
• 3xx
• 4XX: Client Error
• 5XX: Server Error

　　HTTP status Code Daquan

First-Entry Network series notes (4) HTTP requests and responses