RESTful Web Services Four operations Post/delete/put/get

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!!

There are four types of operations in rest mode:

• Post/url Create

• Delete/url/xxx Delete

• PUT/URL/XXX Update or create

• Get/url/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 (/url), and the put operation is on a specific resource (/URL/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 "content" submitted in the same format, both Var_1=value_1&var_2=value_2&....get and post are different, such as the literal, one is get (get), one is post (send). Get is used to tell the server what it needs to get (Url+query), to request a static page (URL), to return the file content directly to the browser, and to provide query parameters (queries) for the content when requesting a dynamic page. 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 content, just submit the content to 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 "artificial"), the length of get is limited to 2048 bytes (browser and server Limited, this is the current IE data, once 1024 bytes), to a large extent, limiting the get used to pass the "storage data" of the ability of the 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.

RESTful Web Services Four operations Post/delete/put/get