Open Stack

On 08/27/2014 06:33 PM, Nataliia Uvarova wrote:
> I doesn't support the idea of removing this endpoint, although it
> requires some efforts to maintain.
> 
> First of all, because of the confusion among users, that it could bring.
> The href to message is returned in many cases, and was seen as canonical
> way to deal with it. (As far as I understand, we encourage users to use
> links we provide and not ids etc). And if you only could  send DELETE
> requests to this url and not GET, that is looking not good.
> 
> And the second. We do have ability get a set of messages by id, by using
> /messages?ids=ids endpoint. By removing ability to get message normal
> way, we could unintentionally force users to use this hacky approach to
> get single message. The cost of support both endpoint is not that much
> higher, than support only one of them.
> 
> As for me, changes in v1.1 is more cosmetic one in the part of
> queues/messages, and it is better to make decision about it in v2, where
> will have more understanding what is needed and what is not.
> 
> It is only my thoughts, I'm not very experienced in Zaqar API yet.
> 
> On 08/27/2014 05:48 PM, Kurt Griffiths wrote:
>> Crew, as we continue implementing v1.1 in anticipation for a “public
>> preview” at the summit, I’ve started to wonder again about removing
>> the ability to GET a message by ID from the API. Previously, I was
>> concerned that it may be too disruptive a change and should wait for
>> 2.0. But consider this: in order to GET a message by ID you already
>> have to have either listed or claimed that message, in which case you
>> already have the message. Therefore, this operation would appear to
>> have no practical purpose, and so probably won’t be missed by users if
>> we remove it.
>>
>> Am I missing something? What does everyone think about removing
>> getting messages by ID in v1.1?


Can I agree with both of you? :D

I agree that getting message by ID is not very useful and also quite
confusing for a messaging service. This is one of those things we agreed
on in the early days that we've had to keep for backwards compatibility.

Unfortunately, as Nataliia mentioned, we can't just get rid of it in
v1.1 because that implies a major change in the API, which would require
a major release. What we can do, though, is start working on a spec for
the V2 of the API.

API v2 sounds like a good topic for a design session, we've already done
a good cleanup of minor things in v1.1 and I believe we can make v2
happen in Kilo.

Thoughts?

Flavio


-- 
@flaper87
Flavio Percoco