How the Web Works (3): Http&rest

We covered the basic Web schema in the first article and then discussed the structure of the Web application in the second article, and it's time to roll up the sleeves to see HTTP and rest up close.

For web developers, it is important to understand HTTP, because HTTP allows information to be passed through a Web application-allowing better user interaction and improving the performance of the site.

What is HTTP?

In the client-server model, the client and server interact with the message as a "request-response" message: The client sends the request and the server responds to the request.

The flow of tracking information is much more complex than it sounds, and both the client and the server follow a common language and a set of rules, so they all know what they want, and that language, or "protocol," is HTTP.

The HTTP protocol defines syntax (data format and encoding), semantics (meaning of the syntax), and instant (speed and order). The exchange of each HTTP request and response between the client and the server can be considered a single HTTP transaction.

HTTP: Main Content

Before we dive into the details of HTTP, there are a couple of things worth mentioning.

First, HTTP is text-based, which means that the exchange of messages between the client and the server is done through bit text, with two parts per message: The first line of a message and a message body.

Second, HTTP is the application-layer protocol, which means that it is just an abstraction layer that standardizes how the hosts communicate. HTTP itself cannot transmit data, it still relies on the underlying TCP/IP protocol to get requests and responses between the two machines.

(To remind you that TCP/IP is made up of two parts, it functions as the Internet's underlying "control system", about TCP/IP introduction, you can see the first article in this series)

Finally, you should have seen the "https" protocol in your browser's address bar, you would think that HTTPS is not http+ "S", the simple answer is approximate, but still a little bit different.

Normal HTTP requests and responses are unencrypted and vulnerable to various types of security attacks. And HTTPS is a more secure way of communicating, it makes the information more secure by encrypting it, it adds a layer of TLS/SSL outside the original HTTP data.

SSL is a security protocol that allows clients to communicate with the server in a secure way over the network, which prevents the message from being tapped and tampered with during network transmission.

Clients typically use a special port 443来 to identify whether a TLS/SSL connection is required. Once the client and server agree to use Tls/ssl to communicate, they negotiate a stateful connection by performing the so-called "TLS handshake", and then the client and server establish a session key that is used to encrypt and decrypt the message when they communicate with each other.

Most websites like Google and Facebook use HTTPS, after all, to make your passwords, personal information, and credit card information safe and secure on the web.

HTTP: Details

With this basic knowledge, let's take a closer look at the structure of HTTP.

We communicate with the GitHub server by accessing https://www.github.com. If you are using Google Chrome or Firefox with the Firebug plugin installed, you can view the details of the HTTP request by looking at the "Network" tab.

HTTP request Header

The HTTP request header typically contains metadata (data about the data) that contains the request type (GET, POST, PUT, DELETE), Path, status code, content type, user agent, Cookie, POST body (sometimes included), and so on.

With the example of accessing GitHub, let's take a closer look at the most important part of the head, and we start with a "Response header":

Request url:https://github.com/(This is the URL we requested)

Request method: Get (the HTTP request method used in this example, equivalent to the browser said: "Hey, GitHub server, put your main to me")

Status code: $ OK (this is a standard way for the server to tell the client that the result of your request is normal.) Status code 200 means that the server successfully found the resource and is sending it to you)

Remote Address: 192.30.252.129:443 (this IP address and port number is the GitHub website we visit, note its port #443 (meaning we are using the HTTPS protocol, not HTTP))

Content encoding: gzip (this is the resource code we accept, in this case, the GitHub server tells us that the content it sends back is compressed, and that GitHub may compress the files so that you can download them with less time.) ）

Content type: text/html; character Set =utf-8 (specifies the representation of the data in the response body, including the type and its subset, which describes the data type, and this subset designates a specific format for the data type. In our example, our text is returned to us as HTML, and the second part specifies the character encoding used for this HTML document, in most cases the UTF-8 used in this example)

Header information also contains a lot of content that the client must send to the server so that the server may know how to respond to the request. Let's look at the "Request Header" section below:

User agent: mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) applewebkit/537.36 (khtml, like Gecko) chrome/47.0.2526.73 safari/537.36 (this represents the software that users use, and sometimes websites need to know that they are as What is browsed, so the browser sends this user-agent string to the server, which the server can use to determine what to access the site for)

Receive code: GZIP,DEFLATE,SDCH (Specifies what encoding the browser will receive for the content, we can see the list of gzip, which is why the GitHub server is able to send content to us in gzip format.) ）

Language of Reception: en-us;q=0.8 (describes the language of the Web page we want to use, in this example, "EN" stands for English)

Host: Github.com (this is self-evident)

cookie:_octo=gh1.1.491617779.1446477115; Logged_in=yes; Dotcom_user=iam-peekay; _gh_sess=somethingfakesomething Fakesomethingfakesomethingfakesomethingfakesomethingfakesomethingfakesomethingfake; User_session=fakesomethingfake Somethingfakesomethingfakesomethingfake; ga=9389479283749823749; tz=america%2flos_angeles (this text is a Web server stored on the user's machine for later retrieval, which is stored as a key-value pair, One of the key-value pairs is that GitHub stores for this request, for example, "Dotcom_user=iam-peekay" is used to tell GitHub that my user ID is Iam-peekay)

TL;DR: What are these key-value pairs?

To make a long story short, we've left a lot of key-value pairs not covered, but how are they generated?

When your browser visits a website at any time, it will look at the cookie that was set up on your computer before the site.

So, if I visit www.github.com, my browser will look for a cookie file that GitHub keeps on my hard drive, and if a cookie file is found, it will send these key-value pairs to the server in the request header.

GitHub Web servers can now use cookie data in different ways, such as displaying content in a user-saved personal configuration, and counting the number of times they visit the site.

If the browser does not find a cookie file-this may be because the browser does not send any cookie data before the website has been accessed or blocked or deleted by cookie--.

In this example, the GitHub server creates a new ID key-value pair with any key-value pairs it needs, and then sends it to my computer via the HTTP header, and my computer saves the information on the hard drive.

HTTP body

As seen above, the service retains most of the important metadata it needs to communicate with the client.

Now go back to the main section.

As you can guess, the subject is the body of the information part, which depends on the type of request, and the body part may also be empty.

In our example, you can see the main part in the "Response" tab, and since we sent a get www.github.com request, the subject contains the Www.github.com HTML page content.

Additional Exercises

I hope this will give you a better understanding of the structure of HTTP, and as an exercise, when you visit www.github.com, you can look at other resource sets (slices, JS files, etc.) that your browser requests.

With this knowledge, we can look at the various HTTP request methods that the client can initiate.

HTTP request method

The HTTP verb or method, which tells the server what to do with the data in the URL, usually indicates a specific resource, and when the client uses a URL that contains an HTTP verb, this tells the server what to do with the resource.

Example:

Get Http://www.example.com/users (Get all users)

POST Http://www.example.com/users/a-unique-id (Create a new user)

PUT Http://www.example.com/comments/a-unique-id (update comment)

Delete Http://www.example.com/comments/a-unique-id (remove comment)

When a client sends a request, it uses one of these verbs to indicate what kind of request, and some of the final verbs are get, POST, put, and delete, such verbs as head and options, but they are seldom used. So we're not going to talk about them in this post.

GET

Get is the most common request method used to read the specified URL from the server.

Get requests are read-only, which means that the data on the server should not be modified-the server should simply get unmodified data. In this way, a GET request is considered a safe operation because the request is one or 20 times, and its effect is the same.

In addition, the GET request is idempotent, which means that you should have the same result for multiple commits and commits once for the same URL, because a GET request simply requests the server data without changing any data on the server.

If the resource of the GET request is successfully found, then the response status code is (OK), if the resource does not exist, it is (not FOUND). (When you access an expired or nonexistent URL, "404 page" is used as an error message)

POST
Post is typically used to create new resources, such as a registration form. But if you want to create a child resource (such as a new user) of a parent resource (http://example.com/users), you can use post, and the resource you commit is the URL to identify its parent resource, so that the server is working on the new resource and will associate it with its parent resource.

Post is neither secure nor idempotent. This is because you commit two or more times to the same post request, which is likely to result in the creation of two identical resources.

Post Request response Status Code 201 (created) with a link to the newly created resource in the header.

PUT

A put is typically used to update a resource by identifying the resource to be updated through the URL and the information in the request body. A put can also be used to create new resources. Put requests are also unsafe operations because they modify the server state, however, it is idempotent, because you send a put modification request to the same resource multiple times, and its effect is the same as when sending the first request.

If the resource is successfully modified, the PUT request response status code is (OK) and returns 404 (not FOUND) if the resource does not exist.

DELETE

Delete is usually used to delete a resource. The delete request is also idempotent, because after you delete a resource, even if you repeatedly send the same delete request multiple times, the result is the same: the resource has been deleted.

If you send multiple delete requests to the same resource, you are likely to get a 404 error message because the server cannot find the resource that has been deleted.

If it is successfully deleted, the delete request response status code is (OK) and returns to (not FOUND) if the delete resource does not exist.

For the above request method, if the server handles an error, it returns 500 (server internal error).

What is rest?

Before we finish this article there is one last part: Rest does not speak of.

You may have heard of "restful apps" before, and it's important to understand what rest means if you use HTTP communication with the client and the server, which is a benefit of following the rest style. (in fact, the HTTP verbs we've defined above will largely show what rest is.) ）

Rest stands for "representational state Transfer", which is an architectural style for designing applications.

Its basic idea is to use "stateless", "Client-server", "cacheable" protocols to communicate between two machines-usually this protocol is HTTP. This is a peculiar way to describe Rest,rest gives you a set of constraints to design applications that make system performance, extensibility, simplicity, modification, visibility, portability, and reliability even better.

The entire content of the constraint is long and you can learn more from here. The purpose of this article is to explore in more depth the following two most important points:

1, interface consistency:
These constraints tell you how to define the interface between the client and the server, so that you can define it in a simple, replicable way, that is to say:

The resource must be identifiable in the request (for example, in a URI with a resource recognizer). A resource, such as data in a database, is data that defines the representation of a resource (such as json,html). Resource and resource representations are separated-the client interacts only with the resource representation.

When a client uses a resource representation, it must have sufficient information to manipulate the resources on the server.

Each message that is exchanged between the client and the server must be self-describing, and this information determines how the messages are processed.

The client must send state data using HTTP principal content, HTTP request headers, query parameters, and URLs. The server must send state data using HTTP principal content, response codes, and response headers.

Note: The HTTP verbs we described above make "interface consistency" an important part because they are consistent with the resources of those operations.

2. No Status:
These constraints indicate that the client request that all state data needs to be processed must be included in the request itself (URL, query parameter, HTTP principal, or HTTP header), and all state data sent by the server needs to be passed in response to the content itself (HTTP header, The status code and HTTP response body) need to be returned to the client.

Side note: The State or application state is the data that the server needs to complete the request.

This means that for each request, we send state information back and forth so that the server does not need to maintain, update, and send the status.

Because this stateless system makes the application more extensible, because in multiple requests, the server does not have to worry about maintaining the same session state, and all the need to get state data can be obtained in the request and response itself.

End language

HTTP is complex, but as you can see, the client-server relationship is a key component.

Designing a restful application requires at least a basic understanding of HTTP, with the above, a better understanding of the mysteries of client-server communication in your next project.

Original link:
Http://www.cnblogs.com/Lau7/p/7886727.html

(go) How the Web Works (3): Http&rest