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]
