*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
>

Reply via email to