PUT or POST?

Http://www.oschina.net/translate/put-or-post

http://my.oschina.net/u/1263964/blog/268932

Both of these methods can update resources at a glance, but there are essential differences between

Specific definition can Baidu, I do not post here, Light said my own understanding

The first explanation is idempotent, idempotent is a term of mathematics, for a single input or no input operation method, if each time is the same result, it is called idempotent

For two parameters, if the incoming value is equal, the result is equal to each incoming value, it is called idempotent, such as Min (A, B)

POST

Used to submit requests, can update or create resources, non-idempotent

For example, in our payment system, the function of an API is to create a collection amount of two-dimensional code, which is related to the amount, each user can have more than two-dimensional code, if the successive calls will create a new QR code, this time with the post

PUT

Used to route update resources to the specified URI, idempotent

Or that example, the user's account QR code is only associated with the user, and is one by one corresponding to the relationship, at this time the API can be put, because each time it is called, will refresh the user account two-dimensional code

For example, an interface for user-generated, received data is user name, password and other related information, then use post

RESTful suggests that all URIs are corresponding resources, so creating a user should not be understood as a behavior where this interface is named:

/user/creation

Creates a new user each time it is called (assuming that the user name can be duplicated)

The Put method is more concerned with the URI of a specific resource, such as updating the current user information, which can be put

/user/me/update

Here with me to refer to the current user, if it is for more user-appropriate interface, you can consider

/user/{uid}/update

Note that the same interface is called multiple times, so long as the submitted data is consistent, the user information is consistent every time, which results in the same result: a specific resource on the server has been updated

When you need to modify a specific resource in the form of an update, how do you decide whether to use put or post?

Quite simply, if the update corresponds to a URI that matches the result of multiple invocations, the put

such as updating a blog post, because the article has a single specific URI, so each update to submit the same content, the results are consistent

/blog/{document_id}/update

Each time the update commits the same content, the final result is inconsistent, using the post

As a very common example, the function of an interface is to reduce the current balance by one value, each commit specifying the value is 100, the interface is as follows

/amount/deduction

Call once, your balance-100, call two times, balance-200

This is the time to use post

4 different levels of restful

Representational status transfer

Personally understood as: the expression of the form of the state transfer

1, only one interface to exchange XML to achieve the entire service

Currently our mobile site service is similar structure, we have two URI interface/mapp/lead and/msdk/safepay

2, each resource corresponds to a specific URI, better than 1 maintenance, but the problem is still obvious, the resource version updates will introduce time-stamp maintenance, resource acquisition and update modification must correspond to different URIs

The current static content (including HTML files) for both PC master and mobile sites is this form

3, in the 2 based on the use of HTTP verb, each URI can have different actions, take full advantage of the HTTP protocol, so naturally incredibly full advantage of the HTTP protocol, such as cache and robustness

HTML4.0 only supports post and get, so both the delete and put operations use post to simulate

In the view of Web developers, if there is data change, use post, if not, use get

So at present, Chinese users see, PC-side implementation of restful very difficult, only mobile support HTML5 browser, can let the front-end to make a try

4, now seems to be more than practical application, Hypemedia control, that is, the intention of restful, reasonable architecture and network-based design to combine to bring a more convenient, powerful communication architecture

This is a little vague, but a hard way, think about it, later to pay water, open the browser, input I have to pay water, on automatic positioning + automatic placement + Auto Payment + Automatic display results, complete the process of payment of water, this is how convenient to understand! Gwy to be unemployed have wood, that help terrible do very simple things, productivity development 1th to eliminate is to hinder productivity development of backward relations of production ...

=================================

By soul Code person at 2013-05-20 08:15

Representational State Transfer (English: representational, Transfer, or rest) is a software architecture style proposed by Dr. Roy Fielding in his doctoral dissertation in 2000.

There are currently three mainstream Web service implementations, as the rest-mode Web services are significantly more concise compared to the complex soap and XML-RPC, and more and more Web services are being designed and implemented in restful style. For example, Amazon.com provides close-to-rest-style Web services for book searches, and the Web services provided by Yahoo are restful.

Should be, do Web services, must master rest Oh ~ ~

There are four types of operations in rest mode,

• Post/uri Create

• Delete/uri/xxx Delete

• PUT/URI/XXX Update or create

• Get/uri/xxx View

The get operation is secure. Security means that the state of a resource does not change regardless of how many times it is done. For example, I use get browse articles, no matter how many times, the article is still there, no change. Of course, you may say that every time you browse the article, the number of views on the article add one, this does not change the state of the resources? This is not contradictory, because this change is not caused by a get operation, but rather by the user's own set of service-side logic.

The put,delete operation is idempotent. Idempotent means that the results are the same regardless of the number of operations performed. For example, I use put to modify an article, and then do the same operation, after each operation the result is not different, delete is the same. By the way, because the get operation is safe, it is naturally idempotent.

The post operation is neither secure nor idempotent, such as a common post repeat loading problem: when we make the same post request several times, the result is that we have created a number of resources.

The significance of security and power is that when the operation does not reach the desired target, we can retry without any side effects on the resource. In this sense, the post operation is often harmful, but many times we still have to use it.

Another thing to note is that the create operation can use post, or put, except that the post is acting on a collection resource (/uri), and the put operation is on a specific resource (/URI/XXX), and then, in a more popular sense, If the URL can be determined on the client, then use put, if it is determined on the server, then use post, for example, many resources use the database self-increment primary key as identity information, and the identity information of the created resource is what can only be provided by the server, this time must use post.

About the confusion of get POST

Say the same thing first, and only understand the same point before you understand why confusion occurs. Both can send data to the server, the submitted "content" [Note 1] The same format, are var_1=value_1&var_2=value_2&....get and post differences such as literal, one is get (get), one is post (send). Get is used to tell the server what to get (Uri+query), a static page (URI) request to return the file content directly to the browser, and a query parameter can be provided when requesting a dynamic page to obtain the appropriate content. Post is used to submit content to the server, mainly for submission, not to request content, that is, the original purpose of post does not require the server to return the content [Note 2], but only submit content for the server processing (mainly storage or processing and then storage). Get and post are confusing because of the misuse of the data processing methods submitted, the data is innocent.

One of the confusing: the field used to query the get commits as storing data in a server-side file or database. You then mistakenly assume that get is used to submit data for storage.

Confusing two: scripting on the server side by processing post-submitted data and returning content. As long as there is data, it can be used to judge how the script is written by the programmer, regardless of the form of the data source (post, get, or the constant of its own default value). There is no problem with this feature, it is just a departure from its original purpose.

Because the data is to be transferred, and the data is in the same format (even if the data format is different, as long as the corresponding data can be extracted). When used, the pigtailed is unavoidable, the get data is used to store and the post data is used to retrieve the returned data. But the two are still different (mainly based on their use and "man" [Note 3], the length of get is limited to 2048 bytes (by browser and server limit, this is the current IE data, is 1024 bytes), to a large extent, limiting the get used to pass "storage data" of the ability to transmit data, So be honest with the search, post there is no such limitation (only the HTTP protocol specification is not size limited, but is limited by the server's processing power), so for large data (generally need to store the data may be larger, than 2048 bytes large) of the delivery has a natural advantage, who let it is Nature born post.

Get submitted data is placed in the URL, the purpose is flexible to the service to submit a retrieval request, you can modify the data in the address bar at any time to change the need to get the content, such as directly modify the page number to jump to another page (of course, it may be 404). The data submitted by the post is placed in the body of the HTTP request in order to submit the data and use it for server-side storage, rather than allowing the user to make too many changes to the data (mainly in the case of a lot of trouble with the URL modification, as long as the URL is changed by clicking on the Address bar), unless the data is specifically edited

Lace: The security of post and get is not very different on the transmission level, but the get method of submitting data by URL is easy to be seen by the human eye, or it can be seen in the history, or it may be visible to the naked eye, which is a local problem.

• Note 1: I emphasize the content, as to the HTTP protocol in the GET and post format everyone is interested to see it yourself.

• Note 2:get mode is mainly to obtain the expected content, that is, uri+query the same content should be the same. Post is primarily a submission, as to whether it is necessary to return a page just for the user experience, such as returning your registration ID when registering, but it's not surprising if you just return a "You've registered successfully" page (even if the data you post is different).

• Note 3: There is a technical difference between get and post about this "man", which is not so pertinent. But from the appearance of the moment to say so, after all, the confusion is also "artificial".

======================

Http://www.restapitutorial.com/lessons/httpmethods.html

Using HTTP Methods for RESTful Services

• Quick-tips
• Resource naming

The HTTP verbs comprise a major portion of our "Uniform Interface" constraint and provide us the action counterpart to the  noun-based Resource. The primary or most-commonly-used HTTP verbs (or methods, as they is properly called) are POST, GET, PUT, PATCH, and DELE  TE.  These correspond to create, read, update, and delete (or CRUD) operations, respectively.  There is a number of other verbs, too, but is utilized less frequently. Of those less-frequent methods, OPTIONS and HEAD is used more often than others.

Below is a table summarizing recommended return values of the primary HTTP methods in combination with the resource URIs:

HTTP Verb	CRUD	entire Collection (e.g./customers)	specific Item (e.g./customers/{id})
POST	Create	201 (Created), ' location ' header with link to/customers/{id} containing new ID.	404 (Not Found), 409 (CONFLICT) if resource already exists.
GET	Read	(OK), List of customers. Use pagination, sorting and filtering to navigate big lists.	(OK), single customer. 404 (not Found), if ID is not Found or invalid.
PUT	Update/replace	404 (not Found), unless you want to update/replace every resource in the entire collection.	(OK) or 204 (No Content). 404 (not Found), if ID is not Found or invalid.
PATCH	Update/modify	404 (not Found), unless you want to modify the collection itself.	(OK) or 204 (No Content). 404 (not Found), if ID is not Found or invalid.
DELETE	Delete	404 (not Found), unless you want to delete the whole collection-not often desirable.	(OK). 404 (not Found), if ID is not Found or invalid.

Below is a more-detailed discussion of the main HTTP methods. Click on a tab for more information about the desired HTTP method.

• POST
• GET
• PUT
• PATCH
• DELETE

The POST verb is most-often utilized to **create** new resources.  In particular, it's used to create subordinate resources.  That's, subordinate to some other (e.g. parent) resource. In other words, when creating a new resource, POST to the parent and the service takes care of associating the new RESOURC E with the parent, assigning an ID (new resource URI), etc.

On successful creation, return HTTP status 201, returning a location header with a link to the newly-created resource with The 201 HTTP status.

POST is neither safe nor idempotent.  It is therefore recommended for non-idempotent resource requests. Making identical POST requests would most-likely result in both resources containing the same information.

Examples:

• POST http://www.example.com/customers
• POST http://www.example.com/customers/12345/orders

PUT or POST?