More recommended RESTful HTTP request verb (verb) as the operation flag. Including GET, PORT, PUT, PATCH, DELETE.
There are so Hu in a RESTful Chinese document, "patch method used to update the local resources," How do we understand?
First explain ancient POST and PUT.
The method of HTTP original definition in [RFC2616], to upload data only POST and PUT.
Maybe it has all updated resources, but there are fundamentally different, and that is semantics. In HTTP, PUT method is defined as idempotent (idempotent) of, POST is not, this is a very important distinction. Popular first explain idempotent, it is a mathematical term, is no operation for a single input or input method, if the same result every time, which is called idempotent. That is, if a network repeated multiple times, the effect is the same, that is idempotent (idempotent).
POST
For submitting a request, you can update or create a resource, a non-idempotent, for example: the most common is
in the user registration function, each commit is to create a user account, this time with POST.
ESTful URL address should be: / user / creation user_name = ...... & pwd = ......?
PUT
For transmitting an update resources to specify a URL, it is idempotent.
For example, change the user password, while the author's account name or password for the user with both a required parameter, but each submission just update the user password, each request covers only the original value.
ESTful URL address should be: / user / {user_id} / modify pwd = **?
With PUT or POST
when you need to update the form to modify a particular resource when determining how to use PUT or POST it?
Very simple, if consistent with the corresponding URI multiple calls to update the results of the PUT. If every time submit the same content, the final result is inconsistent with POST, because she is not idempotent, if repeated every time a new resource is created multiple times corresponding. If the request times out, you need to verify some of them: whether the resource has been created on the server? Then you can try again or check the list of resources? (You can set your own) and other methods for power does not exist this problem, we can safely repeated requests. .
Later, in view of the semantics of POST and PUT lack of functionality and, he joined the PATCH method [RFC5789]. POST and PUT methods difference is obvious, and the PUT and PATCH method is relatively similar, but their use is completely different.
PUT method and the destination address of the requested PATCH method is directly to the resource, and the target of the request is a POST method processor behavior, it is very easy to distinguish. But PUT and PATCH it? The PUT described in the specification for alternative sources, and for updating portion PATCH resources. In fact, this description is not well understood, but we can understand from the reverse structural properties, that is, non-PATCH idempotent. POST method is non-idempotent understandable, because it requests the server to perform an action repeatedly initiate requests may lead to action multiple times (up to create an account).
The goal of this request as PATCH is a resource, a resource update it just does not perform other actions, then what is not idempotent property is it? Note here that, the PATCH and POST methods have a very similar place, a substantial portion thereof is structured data. The physical structure of the POST method is generally multipart / form-data or application / x-www-form- urlencoded PATCH physical structure and method is defined with other specifications. This unstructured entities PUT method is compared with the difference between the largest entity, unstructured PUT method, which is directly replaced with data entity portion to the server's resources.
# Following passage is very important!
PATCH entity is the need to provide a custom program or other protocols parsed executed on the server, in order to modify data on the server. In other words, PATCH request will execute a program, if the duplicate submission, the program may be executed multiple times, resources on the server may cause additional effects, which may explain why it is not idempotent up.
Suppose we have a database to store user information UserInfo, which has userId, Name, Password, Address and other fields. Can your editing needs because, at some particular pages can only modify the password and address, update this time how to do?
People usually (as a disciple save) to the object that contains a complete userInfo userName passed to the back-end modified. This approach is correct, but we missed the point, it will take up more bandwidth. (Of course, in most cases the total resources is still very, very small).
Thus was born patch, which can be transferred only to the portion of the field updates the database to indicate that the request is a partial update, only the rear field of the received updates.
And although put also update the resource, but the front-end requirements must provide a complete resource object, in theory, if you use the put, but did not provide a complete UserInfo, then the missing of those fields should be emptied, although the actual on and will not, but it does take up more bandwidth, here the term sql statement optimization section, so since we know this is just down right.
restful just the standard, the standard mean if we all act accordingly, then, communication costs will be low, development efficiency is high, but not mandatory, so you say in your program from the method name changed patch put no influence, of course, perhaps the future slowly become an unwritten rule, or judge the level of standard, it is natural, because you did not do back-end program on two different treatment according to standard methods, her performance is the same as natural .
Briefly about idempotent (idempotent). In fact, I am not a professional, a lot of information about reference
PUT is idempotent, rather than PATCH idempotent.
Idempotent is a mathematics and computer science concepts, represents an operation performed any number of times the impact on the system with the same time in the computer category.
In HTTP / 1.1 specification idempotent definitional is:
Methods CAN Also have have The Property of "idempotence" in that (aside from error or expiration DELINQUENCY) The Side-Effects of N> 0 Identical Requests IS The Same AS for A SINGLE request.
By definition, idempotent HTTP method refers to a resource request from a plurality of times and should have the same side effects. Idempotence belong to the semantic category, as the compiler can only help to check a syntax error, HTTP specification there is no way to define it by means of message formats such as grammar, this may be one of the reasons it is less attention. But in fact, idempotency is the concept of distributed system design is very important, and the distributed nature of HTTP also determines that it has an important position in HTTP.
Web API HTTP-based protocol is nowadays the most popular form of distributed service delivery. Whether in large-scale Internet applications or enterprise-wide architecture, we are seeing more and more of SOA or RESTful Web API. Why Web API so popular it? I think to a large extent be attributed to a simple and effective HTTP protocol. HTTP protocol is a network application layer protocol for a distributed resource, whether it is to provide a server-side Web service, or a client to consume a Web service is very simple. Coupled with the browser, the development of Javascript, AJAX, JSON and HTML5 technologies and tools, the Internet application architecture design exhibit (Rich Internet from traditional PHP, JSP, ASP.NET and other server-side dynamic web pages to the Web API + RIA application) trends in transition. Web API focused on providing business services, RIA focus on the user interface and interaction design, from the division of two areas of greater clarity. In this trend, Web API design will become a required course for server-side programmers. However, as simple Java language does not mean that high-quality Java program, a simple HTTP protocol does not mean that high-quality Web API. To design a high-quality Web API, also requires in-depth understanding of the characteristics of distributed systems and the HTTP protocol.
Reference: http: //www.cnblogs.com/weidagang2046/archive/2011/06/04/idempotence.html
This article is another reference to a number of blog, I put it earlier in the document content integration and consolidation, as well as add their own understanding, some reference sources already do not know, please contact me if there is a conflict ~ ~ thanks! !
