On 13/02/14 10:30 +0000, Jamie Hannaford wrote:
I noticed a few things about the new 1.1 spec that I thought I'd give feedback on:1. Set Queue Metadata A PUT operation is provided, which does a hard replace of metadata values. Newitems are inserted, and existing items that are not specified are wiped.Nova also provides a POST operation that is more sympathetic - allowing you to update only the values specified, leaving existing unspecified items unmodified. Could a similar operation be added to this API - since there definitely seems like a use case for it.
Neither PUT nor POST are the right methods to use here. I think we discussed this at some point and we agreed on adding a PATCH action for the queue metadata. This still needs to be discussed a bi further though, even the queue metadata utility can be questionable as a public feature. I'd love to hear from you what kind of metadata would you put into the queue and whether you think this is something useful for all users or just operators. The idea behind the queue metadata is to allow users to store information relative to the queue and also customize some of the queue's limits without exceeding the limits configured server side. There are more use cases but I'd love to here some from you
2. Get a Specific Message In the response body, the `href` field is provided as a relative URI - why? Surely absolute URIs are more convenient for the end-user.
This is because the client does the work of joining the relative path to the host address. We had long discussions about whether we should return the absolute URL as opposed to the relative URL. Although relative are less convenient when "curling" the API, they are more convenient when the client is doing this work for you and you have several nodes you could talk to.
3. Deleting Multiple Messages a. How does one delete multiple claimed messages? What would the URI template look like? It is not specified whether this is possible or not. b. If I provide a bunch of IDs, and one of them is a claimed message, what happens? Will it be silently ignored? The behavior is undefined.
Hehe, this is a good one! :) So, as of now it is just possible to do bulk deletes which is a leaky abstraction, TBH. This is a must fix issue for v1.1 because there's a race condition that would allow A to delete a message that was claimed by user B after getting it. So, to answer: a. you just do a bulk delete b. it'd delete the message regardless it is claimed. :(
4. Read a Shard Should these response structures be nested in a top-level "shard" object? Same will the "List Shards" collection.
Yes, there's a plan to make response more consistent, not sure if it is mentioned there. :)
5. The request body for Post Message(s) contains malformed JSON - the `=` should be `:`
Oh mmh, you mean in the spec, right?
Sorry if some of these issues have already been settled or discussed :)
Thanks a lot for raising these questions and for reviewing the API v1.1 spec. Cheers, Fla. -- @flaper87 Flavio Percoco
pgpM0AN3lxcQR.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev