In which cases Idempotent PUT would be useful in REST?

Ok. I have read at several places that using the same PUT URL several times should have the same effect. PUTting data to Api/Student/1234 should either create or update the same student with id 1234.

Now every Url will have a payload of the actual student data that needs to be added or updated in the database. Why not the ID be part of the payload? I can simply PUT data to Api/Student with the payload containing the ID.

You would say that the Url is not idempotent. My question is how will I benefit by making a PUT url idempotent? I understand that GET must be idempotent. But why would PUT need to be idempotent because the client is the one putting the da开发者_开发知识库ta. Calling the same URL Api/Student with payload containing the same student Id will have the same effect each time. So the purpose is solved right?

Please help.

---

You need to have the id in the URI to allow caching proxies to function correctly. If you do

PUT /Api/Student/23

The intermediary cache knows that any copy of /Api/student/23 that it is storing is now out of date and can be flushed from the cache. The same goes for GETs if you don't uniquely identify the resource with the ID then the cache will not be able to store that resource representation independently.

If you follow your argument to the logical extreme then you could say that you don't need student in the URI because that information could be held in the payload. And you are absolutely correct and it is a valid approach, it just is not REST at that point. The REST uniform interface constraint includes "identification of resources" as one of the sub-constraints.

---

According to REST architecture you can use PUT to create a new resource and POST to update an existing resource. Source: http://en.wikipedia.org/wiki/Representational_State_Transfer, search for PUT.

Calling PUT on Api/Student/1234 will mean you want to create the student with the ID 1234. "PUT URL several times should have the same effect"; yes but the effect is to create that student all over again, not update the second time, so it's idempotent like you said but in this way.

Did you actually try to make a PUT request? Are you familiar with how this works? I'll give you a tip: use json encoding ( so you can send both text and binary data ) if you ever need it.

---

The reason that PUT needs to be idempotent is that clients know that if something goes wrong at the network layer (e.g., random disconnect of wireless network) or if the user navigates around, the client can just repeat the PUT without asking the user. It's idempotent; it doesn't matter how many times it gets done (well, as long as its done at least once). This means that what PUT matches is a create of a specific resource, or setting of the properties of a specific resource.

If you do a PUT to /Api/Student/1234, you are working with that specific student record. If you do a PUT to /Api/Student then you are working with all the student records, a mass update. Yes, in theory you could also allow selected update that way, it doesn't have good architectural smell. Encode the naming of the resource in the path. (And if you want a new resource created whose name you don't know yet, use POST of course.)