Again, see the way Joe Gregorio makes order creation reliable:
http://bitworking.org/news/201/RESTify-DayTrader
The trick is to do a create via POST, and then PUT to the URI
returned. To meet the idempotency semantics, the server needs to
simply ignore a second submission (and might reasonably return an
error if a *different* representation is PUT).
Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/
On Jun 19, 2007, at 10:20 AM, Steve Jones wrote:
On 18/06/07, Stefan Tilkov <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
> On Jun 17, 2007, at 7:42 PM, Steve Jones wrote:
>
> > 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.
> If you have only POST - for whatever reason - you need to do
> something else. Examples include http://ietfreport.isoc.org/idref/
> draft-nottingham-http-poe/ and http://www.goland.org/draft-goland-
> http-reliability-00.text
The problem is that creation of a new thing isn't always idempotent,
as an example an invoice must have a new number for every creation and
must refer to a specific transaction. So if you have
http://www.example.org/invoice/A123123 and do a PUT over the top of it
then it needs to bounce if the same request is made twice (as even
though the two elements are data equivalent they can refer to
different orders and invoices).
The reason I was suggesting POST, rather than PUT, was to cover those
cases where creation either kicks off a workflow or means a single
significant event. Hence the question if within REST constraints its
okay to return a 404 on PUTs to uncreated URIs and have POST return a
201 for creations.
>
> Stefan
> --
> Stefan Tilkov, http://www.innoq.com/blog/st/
>
