Hi All, We are planning to introduce the Streaming API support in APIM 4.0.0 release. The streaming API is implemented based on the Async API [1] definition.
*Stream Provider*: Stream provider will generate an event stream and publish to GW via WebSockets/WebHooks/SSE. Stream provider will do all the heavy lifting required to generate the final stream. In the case, to stream data from other providers such as kafka, NATS, MQTT, which does not work as a streaming provider, we have to do the integration via a streaming provider such as streaming integrator. *API Gateway*: Proxy the stream provided by the Stream provider to the client via WebSockets/WebHooks/SSE. Further, it will enforce the policies and publish stats for monitoring. In this release we are going to support webhooks [2] as one of the protocols for Streaming APIs. Webhooks is a way for an app to provide other applications with real-time information. The events are sent to a callback url which is registered by the client in the initial request. With API Manager the user flow to support webhooks implementation can be illustrated in the following diagram The user flow is similar to REST API apart from the two asynchronous message flows in the gateway. As the gateway is stateless, all the requests will be proxied to the streaming provider and the events to the client's call back URLs. 1. We are using websub specification [3] for the message flow implementation, due to the fact that it is widely used and descriptive. 2. The user specifies the callback URL, topic name and optionally a secret in the request. As the topic name comes as a query param in the request in the API all initial requests traffic will be forwarded to the /* resource (without any URL mapping) 3. From GW to SP is another webhooks connection. Therefore, a publicly available unique URL has to be registered in the SP as the gateway callback URL for that connection 4. To separate out the event traffic and the rest API calls traffic we decided to deploy an inbound endpoint as the event receiver (callback URL endpoint). 5. All the events traffic (for all webhooks APIs) will be received by the inbound endpoint. In order to support customized event mediation logic, the event will be redirected to a resource defined in the API. In that way we can have the mediation logic related to both flows (initial request and event) in the same API configuration. 6. As the GW will proxy the initial request and events (will not persist any data), the required information such as client's callback URL, subscription ID which are required in the event flow will be appended to the callback URL. This is because these two message flows are asynchronous, and the only reference is the callback URL (ie. the gateway inbound endpoint URL). Your thoughts on this are highly appreciated. [1] https://www.asyncapi.com/docs/specifications/2.0.0 [2] https://github.com/wso2/product-apim/issues/9431 [3] https://www.w3.org/TR/websub -- *Chanika Geeganage* | WSO2 Inc. (m) +94-77-3522586 | (e) [email protected] <https://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
