... I now remember all the debate about what PUT should do whether it should be create or modify or only modify, or only create... And, as ever, despite REST's "simplicity" there is no definitive answer...
So, reconsidering my earlier answer: PUT doing modification is fine... and as long as we can distinguish between create and modify, that is also good (though it seems not essential to REST in itself)... -- Rob On 7 March 2016 at 08:44, Lorenz Quack <[email protected]> wrote: > > > On 07/03/16 08:14, Rob Godfrey wrote: > >> On 7 March 2016 at 07:06, Julien Charon <[email protected]> >> wrote: >> >>> Indeed, copy paste error on this, sorry. I observed the behaviour not >>> only >>> for DELETE, but also for PUT. >>> I.e. if I try to create a new queue and use a name of a queue that >>> already >>> exists, e.g. "newQueue", the response sent will have HTTP status 200 and >>> no >>> body content. >>> This means a client has no chance to find out that the queue already >>> existed and was not newly created. >>> So, if queue "newQueue" already existed, let's say configured as not >>> durable and the client sends a PUT request to create queue "newQueue" >>> configured as durable, the not durable queue "newQueue" will just >>> continue >>> to exist. The client can only be aware of this if either the broker is >>> restarted and the queue will have disappeared or by checking the >>> configuration of the queue after having created it. >>> >>> I agree if the PUT to create an entity which is not identical on all >> attributes, then it should cause an error. If the object that would be >> created is identical, then I think 200 is correct. >> >> -- Rob >> > > How do you distinguish a PUT "to create an entity" from a PUT to modify an > existing entity? > > Cheers, > Lorenz > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
