If this is a REST endpoint then call it REST. It is very likely that users will want to use HTTPS to use it. Calling it HTTP is a misnomer.
All The Best, Dave Sent from my iPhone > On Jun 7, 2022, at 7:25 AM, Zhengxin Cai <cai19930...@gmail.com> wrote: > > Thanks for bringing this up. > I think building a separate HTTP server to serve REST produce/consume > requests might be a good idea, like FunctionWorkerService, users can choose > to run with broker for simplicity or run as a separate component if user > wants isolation and scale independently. > I think we just missed this option when building V1, I think it's working > considering. > > mattison chao <mattisonc...@apache.org> 于2022年6月6日周一 21:33写道： > >> Hi, Pulsar Community, >> >> We have the PIP-64 that introduces HTTP Rest API for producing/consuming >> messages( >> >> https://github.com/apache/pulsar/wiki/PIP-64%3A-Introduce-REST-endpoints-for-producing%2C-consuming-and-reading-messages >> ). But this proposal does not define the implementation. >> >> However, we already have producer HTTP API at the broker side. But, there >> are some problems, so refactored in this patch: >> https://github.com/apache/pulsar/pull/15876. >> >> Then we add HTTP consumer in this patch: >> https://github.com/apache/pulsar/pull/15942. >> >> But, currently have some ideas that do not reach a consensus. Like @Lari >> Hotaril mentioned at pull request >> https://github.com/apache/pulsar/pull/15942. >> >> It might not be a good idea to add the implementation to the main Pulsar >> Admin API at all. >> >> HTTP consuming would be better to handle in a separate component. PIP-64 >> doesn't determine that this should be part of Pulsar Admin API and we >> should revisit this decision. I think it's a bad idea to add HTTP consuming >> to Pulsar Admin API and brokers. >> >> I want to discuss whether we should implement the HTTP endpoint in the >> broker or separate it at another component(like pulsar-WebSocket). >> >> Best, >> >> Mattison >>
