标签云

微信群

扫码加入我们

WeChat QR Code

They both seem to be sending data to the server inside the body, so what makes them different?


I read in the specs that If the Request-URI does not point to an existing resource [...] the origin server *can* create the resource with that URI. So an implementation of PUT that refuses to create a resource if not present would be correct, right? If so, does this happen in practice? Or implementations usually also create on PUT?

2019年07月24日35分44秒

some additional exception which makes the difference very clear is at next URL - dzone.com/articles/put-vs-post

2019年07月24日35分44秒

What I don't understand is how to implement the idempotency of PUT. in general, most API's will be using auto generation of an ID in case of creating a new resource. and in PUT, you should create a resource if it doesn't exists, but use the ID specified in the URI, but how can you do that if the id generation method is set to be automatic ???

2019年07月24日35分44秒

So in a nutshell: The URI in a POST request identifies the resource that will handle the enclosed entity. The URI in a PUT request identifies the entity itself.

2019年07月23日35分44秒

That which implies a certain function may not actually

2019年07月24日35分44秒

Hi Bhollis, What will happen, if I use POST /books/5? will it throw resource not found?

2019年07月24日35分44秒

I feel the idempotency is the most distinguishing and important difference between PUT and POST

2019年07月24日35分44秒

Hi ChanGan, here's an explanation which Wikipedia gives about your "POST /books/5" case: "Not generally used. Treat the addressed member as a collection in its own right and create a new entry in it."

2019年07月24日35分44秒

What is a record in this context? The question is about HTTP Request.

2019年07月24日35分44秒

not record.. it is resource

2019年07月23日35分44秒

What would POST do if the document/resource is already present? Will it throw an error, or will it just go off OK?

2019年07月24日35分44秒

best short answer

2019年07月24日35分44秒

This seems pointlessly rude, and pedantic in a less-than-useful way. In the example of a PUT you cite, the new entity is, in a RESTful api, a 'new' record - and accessible at that location. It's questionable whether it's a good design choice to allow sub-members be mutable like that (I think it's not ideal), but even were it, you're using a subspecies to attack a lot of useful information. Most of the time, the description as it is usually stated is a great statement of both the RFC's content, summarized, and a statement of usual and customary practice. Also, it won't hurt you to be polite.

2019年07月24日35分44秒

This cannot be upvoted enough. PUT has no place in a REST API. Most of the time, POST indicates the correct semantics.

2019年07月24日35分44秒

I think you have PUT and POST backwards

2019年07月23日35分44秒

Beefster Post to create, Put to update, is that right?

2019年07月24日35分44秒

No. PUT is for actually placing literal content at a URL and it rarely has its place in a REST API. POST is more abstract and covers any sort of adding content that doesn't have the semantics of "Put this exact file at this exact URL".

2019年07月23日35分44秒