Re: [amqp-comment] amqp over http draft

[Gordon Sim <gsim@redhat.com>]

On 24/05/2019 12:47 pm, Clemens Vasters wrote:
> When I have a multiplexing endpoint that accepts regular messages for one-way flows and that also responds to HTTP requests, I know that I have an HTTP request only when the HTTP request tells me that it is one.

Why do you need to know it is an HTTP request? You know it is a GET or a 
POST, PUT, DELETE or whatever from the subject. You know the target. You 
have all the headers. What would you do differently based on having an 
indication of it being HTTP?

> You appear to be advocating for my application having to use all sorts of hints to infer for a message to be an HTTP request, and the design in place makes a clear statement about it.

I'm advocating against munging it in with the method or status. AMQP 
already has one of the most complex type systems around, and a rich 
message format that uses it.

In the use case where an AMQP client makes a request it isn't 
originating in HTTP . It might be ultimately handled by an HTTP service 
or it might be handled by an AMQP service. The seamntics of the request 
are clear and complete regardless.

> If the core of your objection is about simplicity, I don't see how omitting a clear indicator is helping simplicity or how moving that indicator into a property that's aimed at the middleware layer will help simplicity.

I don't care about the indicator. I don't see any value in it. If you 
have uses cases that need it, I would rather it is kept out of the 
subject so that all the other cases that don't need it don't have to pay 
the price for it anyway.