-- Matteo Merli <matteo.me...@gmail.com> On Thu, May 14, 2020 at 12:33 AM Sijie Guo <guosi...@gmail.com> wrote: > > On Wed, May 13, 2020 at 10:31 PM Matteo Merli <matteo.me...@gmail.com> > wrote:
> People can use the HOST header for targeting to a specific broker. > > If applications don't use the HOST header, it will fall back to the > redirection approach as what we did for other REST requests. So the request > goes to the owner broker for consuming and acknowledging messages. > it works with both brokers and proxies and it is the same as other restful > requests. Both reading (and reusing) the host header and following redirections has several issues and gotchas from the application side. With hindsight, we shouldn't have relied on redirections for the admin API either. The major problems are: 1. HTTP client libs and tools by default don't follow redirects. This is easily fixable but causes a lot of confusion and troubleshooting time 2. A service that redirects to a particular host cannot be exposed through a load balancer. This is very important and has also ramifications issues on how the TLS certificates need to be created. 3. After a redirect, most HTTP client libs are not forwarding the Authorization header anymore, for security reasons. In same cases, it's just the default, while in others (eg: Java default HTTP client) it's literally not possible to make it pass the header. Finally, requiring the application to keep the host information around, would complicate a lot the app logic. Just one example: if I get an error while deleting a message, do I need to step back and create a new "session" to read the message again within a new session? All these requirements are really making punches with the objectives of REST. In my view, if one wants to have a "session" kind of behavior, that should rather be done through WebSocket. > > 3. >>> Note that this request must be made to the specific broker > > holding the consumer instance. <<< > > That's not necessary to go on the same host. A shared > > subscription dispatcher will be able to apply the ack even if it's > > received from a different consumer (and it will clean up the pending > > acks). > > > > It is yes for shared subscriptions. But it doesn't work for other types of > subscriptions. > We would like to start with this approach to make it work seamlessly for > different types of subscriptions. > We can look into how to optimize it as it goes. I believe that a simple approach that works with no special requirements for a subset of features is 10x better than trying to expose every single feature but, in the process, making the entire API very convoluted and difficult to use. This is even more true if: 1. The stated goal for this REST API is to offer "easy" access 2. There's already an implementation that is better suited for that kind of task (eg: WebSocket).
