Hi Rajan, Thank you for your feedback! I understand that Websocket has a lot of advantages over HTTP.
HTTP is much simple compared to WebSocket. Especially for people who already program using current admin API, it makes sense for those applications pointing to one web service rather than a different util project which can become very complicated. We are adding those endpoints to separate endpoints. So it doesn't change any existing endpoints. Does that make sense to you? - Sijie On Wed, May 13, 2020 at 2:00 PM Rajan Dhabalia <rdhaba...@apache.org> wrote: > *Hi,I would like to add little history about Websocket vs REST API > implementation in Pulsar. Before open-sourcing Pulsar and WebSocket proxy > in Yahoo, we had implemented and evaluated both WebSocket and REST-HTTP > APIs options and then decided to not introduce REST-API and kept Websocket > proxy solution in Pulsar. Let me add a few points to understand why we > should avoid adding REST API in Pulsar. 1. One of the advantages of REST > architecture is statelessness which means that any server can handle any > request. However, it’s true for Websocket protocol as well but Websoket is > a bi-directional protocol with full duplex communication and client-server > can communicate on a single TCP connection which avoids different overheads > such as authentication on every request that needs to be done on REST-Http > api.2. If client doesn’t use persist connection correctly on REST-HTTP then > every produce/consume request can go to a different server and it will > create a lot of complexity to manage the control flow, producer/consumer > queuing at REST-server which internally manages pulsar-client, clean up > unused resources, etc.3. Performance and scalability: Websocket is highly > scalable and provides higher performance and throughput compare to > REST-HTTP.4. Almost all programming languages and web-browsers > <https://caniuse.com/#feat=websockets> support WebSocket.5. Pulsar is > known > for performance and scalability, so, we try to select solutions that work > with scale and provide better performance.6. Pulsar broker gives an option > to start WebSocket proxy along with broker and that doesn’t require extra > component to manage. So, if one doesn’t want to manage additional component > then one can start with the broker process as well. 7. Other messaging > system also moving away from their legacy REST-HTTP api to WebSocket > because of performance and scalability concerns.* > *So, I think let’s not add this feature in Pulsar but it can be added a > utility project outside of pulsar if it is needed for specific usecases.* > > *Thanks,* > > *Rajan* > > On Wed, May 13, 2020 at 3:25 AM Sijie Guo <si...@apache.org> wrote: > > > Hi all, > > > > Some of the people have been asking for a REST-proxy like equivalent > > component in Pulsar. Pulsar already has a web service that provides the > > management API over a Pulsar cluster. We don't actually need a separate > > component or service for supporting streaming events in and out of Pulsar > > using HTTP. We can just add endpoints to the existing web server to > support > > those functionalities. > > > > I'd like to start a discussion on adding REST endpoints to the current > web > > server for producing, consuming and reading messages. So people can use > > HTTP for streaming events in and out of Pulsar without setting up > > additional components. > > > > The full proposal is written at > > > > > https://github.com/apache/pulsar/wiki/PIP-64:-Introduce-REST-endpoints-for-producing,-consuming-and-reading-messages > > . > > > > Feedback and comments are welcome! > > > > - Sijie > > >
