The search for a restful, as explained below
Operations on resources, including getting, creating, modifying, and deleting resources correspond exactly to the GET, post, put, and Delete methods provided by the HTTP protocol, so rest restricts HTTP operations on a URL resource to four of Get, post, put, and delete
But I found that all useless, concrete what is the use?
Reply content:
The search for a restful, as explained below
Operations on resources, including getting, creating, modifying, and deleting resources correspond exactly to the GET, post, put, and Delete methods provided by the HTTP protocol, so rest restricts HTTP operations on a URL resource to four of Get, post, put, and delete
But I found that all useless, concrete what is the use?
I understand that your question should be "what is the use of changing a traditional PHP web interface into a RESTful web interface?" ”
In fact, it is better to use the word "advantage" instead of "usefulness", because the traditional web interface implementation is also able to achieve business needs (so this is not a necessary thing, need to decide whether to use the overall business needs), and the use of "restful style" will have some additional "benefits":
- A unified style makes it easier for the parties to interact and better compatible (this is a common benefit of all that follows a certain norm, just as everyone speaks Mandarin, and it's easier to communicate.)
- The operation of the resource exactly corresponds to the corresponding HTTP action (GET, POST, PUT, DELETE), and these actions just can satisfy our need to operate the resource state, that is, what kind of action to choose the state of the resource, And these actions are provided by the HTTP protocol itself, how harmonious and natural ah (is the title of the main extract content)
- The impact of the request is clear, or the side effects are clear, such as get must be secure, put and delete must be idempotent, post is definitely unsafe (this is definitely based on the design of the API completely follow the "restful style")
- Good "restful style" uri design, can make the function and the overall structure of the Web interface more clear, just through the URI can easily infer what interface is to do, and the correlation between multiple resources
- Use HTTP content negotiation to implement multiple representations of a resource, such as a requester's ability to put the format it needs into the Accept field of the header information (such as Accept:text/json), This way the same URI can output multiple formats and no longer need to add a Type=json parameter to the URI.
- Client, proxy server, etc. can be processed according to the HTTP protocol specification, such as cache
- ... There may be some benefits I have not summed up (there will be some deficiencies, of course).
Above, the main point is the "restful style" compared with the traditional design of the benefits, but the most important and let the reason for restful, should be restful in the implementation of network Services (Web service) than Xml-rpc/soap and other protocols more lightweight, With better transparency and scalability, this can be explained a lot, no longer repeat, recommend the following 2 partial articles for further understanding.
Nanyi: Understanding the RESTful architecture
REST vs Xml-rpc vs Soap–pros and cons
Why is restful popular? Plainly, for one reason: simple.
For API consumer, developing and debugging restful APIs requires only curl.
No client code is generated automatically compared to soap. Compared to thrift, restful also has the huge overhead that the HTTP protocol brings.
Do not understand the thing can temporarily not touch, if need to use to learn again. If you're in the mood for restful words, Wikipedia has a bunch of links to learn about its meaning, its role, its applications, and related technologies such as soap.
Rest is an HTTP-level thing that has nothing to do with PHP or any other language. It is a custom of the customary HTTP request semantics, or the habit of opening and managing server resources, not something specific to the technical level. As with all the other habits, conventions, you can totally not abide by it, while observing restful nature will bring some advantages (such as get and put are idempotent, when initiating and processing requests can be a lot less to verify the consistency of the logic).
A good example of this is Couchdb's restful api:http://wiki.apache.org/couchdb/http_document_api.
The other answers are good, and here's a brief look at my view from another angle.
If you're just doing a one-time project, rest is an option, you just have to get the data right.
If you are doing your own product, then for the maintainability of the code, you may refer to the rest standard, the team unified, can rest on rest, the purpose is to reduce communication costs, improve productivity, morale (let everyone feel that they are in a NB team)
If you are an open platform, especially a world-class open platform such as FB and Twitter, then you have no choice, the whole world is watching, a change in the API will lead to countless saliva and news reports, when it may also cause bugs. Please weigh the situation yourself.
Personal opinion: I generally work in the second state, the pursuit of production efficiency. Can clearly tell you, rest can not guarantee the productivity of the increase, appropriate use, see the situation to use, to learn but do not tangle.
My advice is to
1, change a language.
I also find it hard to believe that I have not been exposed to any knowledge of HTTP for the year I was a beginner of PHP. And when I wrote Python and node. js, I ran into it the next day. Forcing themselves to inquire about information, and then learned.
The same problem also, PHP beginners have a few know: buffer,bdd,cgi and so on ...
2, read the "HTTP authoritative guide", a book known as reading a monthly salary at least to get 1w books.
The result of the implementation is the same as the traditional soap, which provides a Web service, but is much easier to access and style.