An interesting question--http is "Hypertext Transfer Protocol" or "Hypertext Transfer Protocol"

Recently in the "HTTP diagram" This book, the book mentions the domestic translation of the name of the HTTP protocol, and give some friends to discuss the original link, I looked at a bit of interesting, and I also think that translation for understanding the agreement itself is very important, the collation of some ideas.

The full name of HTTP is Hypertext Transfer Protocol, and the main concern is how Transfer should translate.

Here's what to organize:

　Li Yu:

　　1. Paper Interpretation

In the IETF RFC, the meaning of "transport" (transmission) means: from end-to-end (for example, from Ip1:port1 to ip2:port2) reliably transporting bits, which is the 3rd Transport layer in the TCP/IP protocol stack (transport Layer) protocol.

The meaning of "transfer" is to perform some operation by transferring some operation primitives with operational semantics between the client-server side. "Transfer" is the concept of Layer 4th application layer in the TCP/IP stack, not the concept of Layer 3rd Transport layer. The "transfer" shift is the operation primitive with explicit operational semantics, rather than the bit stream without operational semantics.

　　Location of the 2.HTTP protocol in the TCP/IP protocol family

HTTP is actually an application protocol. Http/ftp/nntp ..... Are all application layer protocols. Transfer is the concept of the application layer. Transmission of the matter, TCP+UDP has done very well.

But in the spirit of how bold people have the revolutionary optimistic adventurism, not to use HTTP as a transmission protocol, and indeed can not die. But this is inefficient usage and will pay some price.

　　3.HTTP Designer Dr. Fielding's explanation

Dr. Roy Fielding, one of the HTTP customizer, used "transfer" in his thesis [1] (6.5.3) to express the "transfer of State" (Representational, "transfer") rather than "transport." This is because the English word "transfer" in different contexts of ambiguity, do not misunderstand.

6.5.3 HTTP is not a Transport Protocol

HTTP is isn't designed to be a transport protocol. It is a transfer protocol in which the messages reflect the semantics of the Web architecture by performing actions on Res Ources through the transfer and manipulation of representations of those resources. It is possible to achieve a wide range of functionality using this very simple interface, but following the interface is R Equired in order for HTTP semantics to remain visible to intermediaries.

Try translating:

HTTP is not designed to be a transport protocol. It is a transfer protocol that reflects the meaning of the Web schema by transferring and manipulating resource representations. It enables a very wide range of function demands through a simple interface, while the interface is necessary, which makes the semantics of HTTP visible to intermediate media.

Design and development of 4.HTTP protocol

Why the HTTP protocol is designed and designed to do something, the guiding ideology is rest. Rest is the golden mean, no mystery.

The biggest difference between HTTP 1.0 and HTTP 1.1 is what I'll explain in detail next.

HTTP 1.0 is basically a server-side static file operation protocol, and there is no abstract resource concept, HTTP 1.0 think the Web server is a lot of static files. The transfer inside HTTP 1.0 is the transfer and transfer of files. Some people interpret it as a transmission, and it seems to be possible. But in the protocol, the transmission of transport in fact refers to the handling of the bit level of menial work.

How to support dynamic content well is a major issue to be addressed by the HTTP 1.1 protocol. Therefore, a new concept called resources is invented, and it is an abstract tool to note that resources are similar to objects in object-oriented programming. Resources can not only represent a server-side file, a database in a record of such specific things. It can be more abstract and more abstract. Once you have the resources, you need to design a unified interface to manipulate the resources. Otherwise, each resource operates differently, and doing so can severely reduce the scalability of your Web application.

　　Chen Ruijie-Puppy

Actually speaking, HTTP is really similar to the post office, you go to the letter, the envelope of things, such as address, zip code, there is a semantic, you can be regarded as the "application layer" of things, you through the letter "transfer" your ideas to each other; This letter.
Corresponds to the content of the HTTP protocol, request header, response header, is the meta-information on the envelope, body is your letter content. HTTP is very dependent on these meta-information, it is not concerned about how the whole thing is delivered to the other hand, the transmission has TCP, IP is done.

In fact, to really understand the difference, it is necessary to understand the concept of resources, resources are abstract concepts, you can not really exchange a resource entity on the network, you only operate the expression, the resources can never be directly touched, in the rest architecture, the server and the client can only communicate through the expression of resources, not the resources themselves, This is why it is called "transfer" to call this operation. Transfer representations, not transport resources.

　　

　　Reference Documentation:

http://www.ituring.com.cn/article/1817#

http://www.ituring.com.cn/article/937

Http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm

An interesting question--http is "Hypertext Transfer Protocol" or "Hypertext Transfer Protocol"