HTTP POST GET Essential differences in detail

 

A principle difference

Generally in the browser to enter the URL access to resources are through the Get method, in the form submission, you can specify the way to submit the method is get or post, the default is get commit

HTTP defines different ways to interact with the server, with 4 basic methods, namely Get,post,put,delete

URL full name is a resource descriptor, we can think: a URL address, which is used to describe a network of resources, and HTTP get,post,put,delete corresponding to this resource, change, increase, delete 4 operations. Here, everyone should have a general understanding, get is generally used to get/query resource information, and post is generally used to update the resource information ( personally think this is the essence of get and post, but also the intention of the Protocol designer, other differences are specific manifestations of the difference ).

According to the HTTP specification, get is used for information acquisition and should be secure and idempotent.

1. The so-called security means that the operation is used to obtain information rather than modify the information. In other words, get requests generally should not have side effects. That is, it simply gets the resource information, just like a database query, without modification, adding data without affecting the state of the resource.

* Note: The meaning of security here is simply non-modification information.

2. Idempotent means that multiple requests to the same URL should return the same result. Here I'll explain the concept of idempotent :

　　 Power, etc.(Idempotent, Idempotence) is a mathematical or computer concept, common in abstract algebra.
　　 =abs (ABS (a)).
For binocular operations, it is required that when the two values of the participating operations are equal, if the results of the operation are equivalent to the two values of the participating operations, the exponentiation of the operation, such as a function of the maximum value of two numbers, is in the power of the real concentration, that is, max (x,x) = x.

But in practical applications, the above 2 rules are not so strict. Cite examples of other people's articles: for example, the front page of news sites is constantly being updated. Although the second request returns a different batch of news, the operation is still considered safe and idempotent, as it always returns the current news. Fundamentally, if the goal is that when a user opens a link, he can be confident that the resource is not changed from its point of view.

According to the HTTP specification, post represents a request that may modify resources on the server. Continue to cite the example above: or the news to the website as an example, readers of the news to publish their own comments should be done through post, because after the comments submitted site resources have been different, or that the resources have been modified.

It probably says something about the original rationality of Get and post in the HTTP specification. But in the actual time, many people do not follow the HTTP specification to do, the cause of this problem is many, for example, say:

1. Many people are greedy and use get when updating resources, because the post must go to the form (form), which can be a bit troublesome.

2. The increase of resources, delete, change, check operation, in fact, can be completed through get/post, do not need to use put and delete.

3. Another is that the early but web MVC framework designers did not consciously look at and design URLs as abstract resources. A more serious problem is that the traditional Web MVC framework basically supports only the Get and post two HTTP methods, and does not support the put and delete methods.

* Simply explain that MVC:MVC is originally present in the desktop program, m refers to the data model, v refers to the user interface, and C is the controller. The purpose of using MVC is to separate the implementation code for M and v so that the same program can use a different representation.

The above 3 points typically describe the style of the stereotype (no strict adherence to the HTTP specification), with the development of the architecture, there is now rest (representational state Transfer), a set of new styles to support the HTTP specification, here is not much to say, you can refer to the RESTful Web Services.

Two forms of expression difference

Figuring out the difference between the two principles, let's look at the difference in their actual application:

To understand the difference between the two in the transmission process, let's look at the format of the HTTP protocol:

HTTP request:

<request line>

<blank line>

<request-body>]

In an HTTP request, the first line must be a request line, which describes the type of request, the resources to be accessed, and the HTTP version used. This is followed by a header section that describes the additional information that the server will use. After the header is a blank line, then you can add any additional data [called the body].

Examples of Get and post methods:
Get/books/?sex=man&name=professional http/1.1
Host:www.wrox.com
user-agent:mozilla/5.0 (Windows; U Windows NT 5.1; En-us; rv:1.7.6)
gecko/20050225 firefox/1.0.1
Connection:keep-alive

post/http/1.1
Host:www.wrox.com
user-agent:mozilla/5.0 (Windows; U Windows NT 5.1; En-us; rv:1.7.6)
gecko/20050225 firefox/1.0.1
content-type:application/x-www-form-urlencoded
Content-length:40
Connection:keep-alive
(----empty line here----)
Name=professional%20ajax&publisher=wiley

With the above understanding and examples of HTTP requests, let's look at the differences between the two ways to commit:

(1) Get submit, the requested data will be appended to the URL (that is, to place the data in the request line), in order to split the URL and transfer data, multiple parameters with & connection; for example:login.action?name=hyddd& Password=idontknow&verify=%e4%bd%a0%E5%A5%BD. The encoding format of the URL is ASCII, not Unicode, which means that you cannot include any non-ASCII characters in the URL, all non-ASCII characters need to be encoded and retransmitted, and the URL encoding can be referenced by: http://kb.cnblogs.com/page/133765/.

Post submission: Place the submitted data in the package of the HTTP packet. In the example above, the red font indicates the actual transfer data

As a result, the data submitted by get is displayed in the Address bar, while the post is submitted, the address bar does not change

(2) The size of the transmitted data: first of all: the HTTP protocol does not limit the size of the transmitted data, and theHTTP protocol specification does not limit the length of the URL.

The main limitations in the actual development are:

GET: Specific browsers and servers have restrictions on URL length, such as IE's limit on URL length is 2083 bytes (2k+35). For other browsers, such as Netscape, Firefox, etc., there is theoretically no length limit, and its limitations depend on the support of the operating system.

Therefore, for a get commit, the transmitted data is limited by the URL length.

POST: The theoretical data is not limited because it is not transmitted via a URL. However, the actual Web server will be required to limit the size of the post submission data, Apache, IIS6 have their own configuration.

(3) Security:

. The security of post is higher than the security of get. Note: The security described here is not the same concept as the "security" mentioned in get above. The meaning of "security" above is simply not to make data changes, and the meaning of security here is the meaning of true security, such as: submit data through get, user name and password will appear in plaintext on the URL, because (1) the login page may be cached by the browser, (2) Other people to view the browser's history, Then others can get your account number and password, in addition, using get to submit data may also cause Cross-site request forgery attack

(4) The HTTP GET,POST,SOAP protocol is run on HTTP
1) Get: The request parameter is appended to the URL as a sequence of key/value pairs (query string)
The length of the query string is limited by the Web browser and Web server (ie supports up to 2048 characters) and is not suitable for transporting large datasets at the same time, it is unsafe
2) Post: The request parameter is transmitted in a different part of the HTTP header (named entity body), which is used to transfer the form information, so the Content-type must be set to: application/ X-www-form-urlencoded. The post is designed to support user fields on Web Forms, and its parameters are also transmitted as key/value.
However: it does not support complex data types, because post does not define the semantics and rules for transferring data structures.
3) Soap: is a dedicated version of HTTP POST, followed by a special XML message format
Content-type is set to: Text/xml Any data can be XML

Three HTTP Responses
1. HTTP response Format:

<status line>
<blank line>
[<response-body>]

The only real difference in response is that the first line uses state information instead of the request information. Status line describes the requested resource situation by providing a status code.

HTTP Response instance:

http/1.1 OK
Date:sat, Dec 2005 23:59:59 GMT
Content-type:text/html;charset=iso-8859-1
content-length:122


Wrox Homepage


!--body goes here-->


2. The most commonly used status codes are:

(OK): The resource was found and everything is OK.
304 (not MODIFIED): The resource has not been modified since the last request. This is commonly used for browser caching mechanisms.
401 (Unauthorized): The client does not have permission to access the resource. This usually causes the browser to require the user to enter a user name and password to log on to the server.
403 (FORBIDDEN): Client failed to get authorization. This is usually followed by an incorrect user name or password that was entered after 401.
404 (Not FOUND): The requested resource does not exist at the specified location.

Four Complete examples:

Example:

HTTP GET

Send

Get/demowebservices2.8/service.asmx/cancelorder? Userid=string&pwd=string&orderconfirmation=string http/1.1
Host:api.efxnow.com

Reply

http/1.1 OK
Content-type:text/xml; Charset=utf-8
Content-length:length

<?xml version= "1.0" encoding= "Utf-8"?>
<objplaceorderresponse xmlns= "https://api.efxnow.com/webservices2.3" >
<Success>boolean</Success>
<ErrorDescription>string</ErrorDescription>
<ErrorNumber>int</ErrorNumber>
<CustomerOrderReference>long</CustomerOrderReference>
<OrderConfirmation>string</OrderConfirmation>
<CustomerDealRef>string</CustomerDealRef>
</objPlaceOrderResponse>



HTTP POST

Send

Post/demowebservices2.8/service.asmx/cancelorder http/1.1
Host:api.efxnow.com
content-type:application/x-www-form-urlencoded
Content-length:length

Userid=string&pwd=string&orderconfirmation=string

Reply

http/1.1 OK
Content-type:text/xml; Charset=utf-8
Content-length:length

<?xml version= "1.0" encoding= "Utf-8"?>
<objplaceorderresponse xmlns= "https://api.efxnow.com/webservices2.3" >
<Success>boolean</Success>
<ErrorDescription>string</ErrorDescription>
<ErrorNumber>int</ErrorNumber>
<CustomerOrderReference>long</CustomerOrderReference>
<OrderConfirmation>string</OrderConfirmation>
<CustomerDealRef>string</CustomerDealRef>
</objPlaceOrderResponse>



SOAP 1.2

Send

Post/demowebservices2.8/service.asmx http/1.1
Host:api.efxnow.com
Content-type:application/soap+xml; Charset=utf-8
Content-length:length

<?xml version= "1.0" encoding= "Utf-8"?>
<soap12:envelope xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd= "http://www.w3.org/2001/ XmlSchema "xmlns:soap12=" Http://www.w3.org/2003/05/soap-envelope ">
<soap12:Body>
<cancelorder xmlns= "https://api.efxnow.com/webservices2.3" >
<UserID>string</UserID>
<PWD>string</PWD>
<OrderConfirmation>string</OrderConfirmation>
</CancelOrder>
</soap12:Body>
</soap12:Envelope>

Reply

http/1.1 OK
Content-type:application/soap+xml; Charset=utf-8
Content-length:length

<?xml version= "1.0" encoding= "Utf-8"?>
<soap12:envelope xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd= "http://www.w3.org/2001/ XmlSchema "xmlns:soap12=" Http://www.w3.org/2003/05/soap-envelope ">
<soap12:Body>
<cancelorderresponse xmlns= "https://api.efxnow.com/webservices2.3" >
<CancelOrderResult>
<Success>boolean</Success>
<ErrorDescription>string</ErrorDescription>
<ErrorNumber>int</ErrorNumber>
<CustomerOrderReference>long</CustomerOrderReference>
<OrderConfirmation>string</OrderConfirmation>
<CustomerDealRef>string</CustomerDealRef>
</CancelOrderResult>
</CancelOrderResponse>
</soap12:Body>
</soap12:Envelope>

http://blog.csdn.net/gideal_wang/article/details/4316691

HTTP POST GET Essential differences in detail