RE: [amqp-comment] amqp over http draft

[Clemens Vasters <clemensv@microsoft.com>]

What I have in mind is that a single endpoint (AMQP node) can deal with HTTP requests and then also be the source and target for other messages, possibly even handle a different RPC mapping concurrently (Thrift-over-AMQP?, gRPC-over-AMQP?, Avro-over-AMQP?), or accept/emit CloudEvents compliant with its AMQP binding.

"to" surely is one way to keep those endpoints distinct, but my preference would be for the address to reflect application concepts rather than protocol details or choices; I would find it sad requiring having "/devices/2278283383/thrift" and "/devices/2778283383/http" in the address of a device gateway endpoint for issuing commands. That is not to say that I wouldn't want a resource graph modeled into the endpoint as you'll commonly see it with HTTP, e.g. /devices/2778283383/config. 

I think yesterday's proposal will work for that. The producer of the request and the response SHOULD add the request/response property and everyone, especially intermediaries, who don't care about it can safely ignore it since it really only matters to the receiving dispatchers.



-----Original Message-----
From: Gordon Sim <gsim@redhat.com> 
Sent: Mittwoch, 29. Mai 2019 13:35
To: Clemens Vasters <clemensv@microsoft.com>; amqp-comment@lists.oasis-open.org
Subject: Re: [amqp-comment] amqp over http draft

On 28/05/2019 2:42 pm, Clemens Vasters wrote:
> Scenario:
> a) one set of paired links forming a bi-directional channel
> b) an HTTP service at each end, forming a "dialog" or "callback" interface.
> c) the services have an ongoing bi-directional conversation, each acting towards the other as client. That's not at all outlandish in IoT.
> d) the "client" service also sends telemetry events multiplexed with 
> requests
> 
> Here, I need to triage HTTP requests and HTTP responses at the endpoints to the right correlators and then handlers and also have messages that are one-way telemetry data that I want to dispatch elsewhere.

Would the 'to' field not be a good way to indicate different 'targets'? 
I.e. requests and telemetry would use different addresses and responses would of course use the reply-to address from the request they are in answer to.