标签云

微信群

扫码加入我们

WeChat QR Code


Hi Brian .. the more i read this, the more it makes sence. I'm assuming that some browsers (or browser versions) do not support PUT or DELETE? if that's the case, do we use POST instead?

2018年10月23日29分25秒

Hi Pure.Knome; Web browsers support them all, also any HTTP library should support them all as well.

2018年10月23日29分25秒

I would recommend buying this book by the way if you want to learn all about REST oreilly.com/catalog/9780596529260

2018年10月23日29分25秒

Brian: a few more questions about your PUT examples. >> PUT /questions/<new_question> Why would you do that, instead of doing >> PUT /questions/ because all the data in the form will be used to create the new resource? (continued next comment)...

2018年10月23日29分25秒

Brian R. Bondy, Thanks for your great answer. POST request to existing resource is described as "appending" in oreilly's restful book(pg:100,101), contrary to your general "modifying" term. After all, to append is more specific than to modify - which may convey "PUT to an existing resource" - and semantically sounds more correct for POST - adding new resource to the specified link, either by appending to or creating a child resource to that.

2018年10月23日29分25秒

Wrong. PUT must be idempotent. You must be able to make the same PUT request many times, with no effect after the first time. So, creating a resource with every PUT request is not idempotent.

2018年10月23日29分25秒

"Methods PUT and DELETE are defined to be idempotent, meaning that multiple identical requests should have the same effect as a single request.", using put at a URI that doesn't currently make a Resource available can create a resouce. Immediately PUTting again would just do it again which would have no effect. In this way you're creating a resource, but the query is still idempotent. If you later come back and wish to change the resource, you man PUT to the same URI with different data (which would be a different request and could itself be repeated any number of times with the same result).

2018年10月23日29分25秒

Actually, take a look at the answer that received 25 votes above it's stated that PUT can be used to create or replace a resource.

2018年10月23日29分25秒

Creation only works as long as specifying the ID of a new resource is allowed. While the is possible, it is more often more convinent for the user to POST to /collection and be returned links that include the new id:

2018年10月23日29分25秒

aehIke Creation of a new resource by PUT does not make it non-idempotent since the idea is that if I 'PUT /items/10' and item 10 didn't exist prior, then it will just be created. However if I 'PUT /items/10' again for the second time, well now it already exists so it will just be replaced hence idempotence is preserved since an subsequent PUT requests have no new side effect. (Of course that is assuming that I keep on putting the same exact item each time)

2018年10月23日29分25秒

Out-of-band URI conventions are NOT RESTful. Quoting Fielding himself: "A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations.."

2018年10月23日29分25秒