On Jun 19, 2007, at 10:08 AM, Marc de Graauw wrote: > Stefan Tilkov: > > | > So I'm assuming there is no issue with > | > outlawing PUT (within a system) on new resources and just > | using POST? > | > | PUT is nice because it's [supposed to be] idempotent. POST is not. > | This means that a client is allowed (within REST's constraints) to > | retry a PUT if it hasn't received a response. > > Right, but POST isn't necessarily non-idempotent: it may be > idempotent or > not. >
You are right, I should have written "PUT is defined to be idempotent (by the spec), POST is not - which means POST can or cannot be idempotent". Seems a little like splitting hairs, but OK. > In fact, reliability approaches such as the ones you refer to below > are > ways of making POST idempotent. This would reduce the original > question to: > if I take the trouble to implement some reliability protocol for my > app, and > thus make all my POSTs idempotent, is OK to use just POST for new > resources? > > Yes, if you want URIs to always be created by the server. > | If you have only POST - for whatever reason - you need to do > | something else. > > If you have both PUT and POST, you need something else too - for > the POSTs. > No. I can do all the idempotent stuff via PUT. There might be some cost (such as additional roundtrips), but a solution for idempotent POST is not mandatory. See e.g. http://bitworking.org/news/201/RESTify-DayTrader Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/ > > > | Examples include http://ietfreport.isoc.org/idref/ > | draft-nottingham-http-poe/ and http://www.goland.org/draft-goland- > | http-reliability-00.text > > Marc de Graauw > > www.marcdegraauw.com > > >
