Hi Lorenz,
Ok, I wasn't aware of that. I agree that a 4XX response would violate the spec, so it's correct the way It's implemented. Best regards, Julien Avitech GmbH Engineering AxL Tel.: +49 (0)7541/282-177 Fax: +49 (0)7541/282-199 e-mail: [email protected] ________________________________________________ Avitech GmbH Principal Office: Bahnhofplatz 1 | 88045 Friedrichshafen | Germany Court Registration: Amtsgericht Ulm | HRB 728293 Geschäftsführer/Managing Director: Jon Joseba Goyarzu Caño http://avitech.aero This message may contain confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. -----Ursprüngliche Nachricht----- Von: Lorenz Quack [mailto:[email protected]] Gesendet: Montag, 7. März 2016 10:31 An: [email protected] Betreff: Re: AW: potential java broker REST API bug Hi Julien, As I alluded to in my other eMail, PUT can be used for both creation and modification. The specification [1] has the following to say: "The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload." and "If the target resource does not have a current representation and the PUT successfully creates one, then the origin server MUST inform the user agent by sending a 201 (Created) response. If the target resource does have a current representation and that representation is successfully modified in accordance with the state of the enclosed representation, then the origin server MUST send either a 200 (OK) or a 204 (No Content) response to indicate successful completion of the request." So I believe we do follow the spec and returning 4xx would violate it. Kind regards, Lorenz [1] https://tools.ietf.org/html/rfc7231#section-4.3.4 On 07/03/16 08:39, Julien Charon wrote: > Sorry I'm wrong regarding PUT. > When the queue does not exist and is created, the broker returns HTTP status > 201 and an HTTP header "Location" is set in the response. > If the queue already exists, the broker return HTTP status 200 and the > "Location" header is not set. So there is a way to determine if the queue > already existed or not. > However, in my opinion some 4XX code would be better. > > > Best regards, > > Julien > > Avitech GmbH > Engineering AxL > Tel.: +49 (0)7541/282-177 > Fax: +49 (0)7541/282-199 > e-mail: [email protected] > ________________________________________________ > Avitech GmbH > Principal Office: Bahnhofplatz 1 | 88045 Friedrichshafen | Germany > Court Registration: Amtsgericht Ulm | HRB 728293 > Geschäftsführer/Managing Director: Jon Joseba Goyarzu Caño > http://avitech.aero > > This message may contain confidential information and is intended only for > the individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and delete > this e-mail from your system. > > > -----Ursprüngliche Nachricht----- > Von: Rob Godfrey [mailto:[email protected]] > Gesendet: Montag, 7. März 2016 09:14 > An: [email protected] > Betreff: Re: potential java broker REST API bug > > 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] For > additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
