L'utilizzo di API basate su eventi è diventato fondamentale per soddisfare la domanda dei clienti e fornire una migliore esperienza utente. Poiché esistono diverse differenze fondamentali tra le API REST e le API asincrone, l'utilizzo di una soluzione di gestione API standard può essere difficile. La giusta soluzione di gestione delle API dovrebbe combinare le tradizionali funzionalità di gestione delle API con un'architettura basata sugli eventi, per offrire un enorme valore aggiunto e per espandere la portata e l'adozione del business

2. Iscriviti al gruppo Linkedin WSO2 Italia Club per entrare nella community italiana,
conoscere la tecnologia WSO2 e condividere strategie di integrazione e use cases

3. APIM 4.0 & events based approach
Streaming APIs in WSO2
API Manager
In addition to REST/SOAP compatibility, WSO2 API Manager 4.0 now
offers first-class support for streaming APIs.
Now, it is possible to expose an event stream as a managed API with all
the necessary Quality of Services (QoS), such as applying security,
rate-limiting, and analytics.
Streaming APIs are used within an event-driven architecture (EDA) in
order to support real-time/near real-time experiences. Applications or
servers that produce events, publish those events to certain topics. The
clients who are interested in the specific type of events subscribe to the
topic(s) corresponding to those events, which enables them to receive
events as they are published to the topics without separately sending a
request.

4. APIM 4.0 & events based approach
Streaming APIs in WSO2
API Manager

5. APIM 4.0 & events based approach
Streaming APIs in WSO2
API Manager

6. APIM 4.0 & events based approach
React in Real-Time
with Event-Driven
APIs
Managing
Event-Driven APIs

7. APIM 4.0 & events based approach
Streaming APIs in WSO2
API Manager
• WebSockets
• Server-Sent Events (SSE)
• WebHooks

8. APIM 4.0 & events based approach
WebSockets

9. APIM 4.0 & events based approach
Server-Sent Events (SSE)

10. APIM 4.0 & events based approach
WebHooks
The subscription flow is the process of a client subscribing to a certain topic. The process can be
broken down into the following steps.:
• Initially the client sends the subscription request to the API gateway.
• Then, the gateway notifies the event hub about the subscription request and the event hub stores
the subscription in the database for persistence.
• Thereafter, the event hub notifies all the gateways about the newly created subscription.

11. APIM 4.0 & events based approach
WebHooks
Response flow is the process of delivering the event/notification to the subscribed clients. In the
response flow:
• The event is initiated from the WebHook provider and it calls the gateway.
• The gateway publishes the event to the relevant clients who are subscribed to the topic.
The subscribers are fetched from the in-memory cache of the gateway, and, in case of a restart of the
gateway, subscribers are fetched from the database through the event hub.

12. APIM 4.0 & events based approach
WebHooks

13. APIM 4.0 & events based approach
Value addition with
Streaming APIs
In order to utilize a streaming API in a modern-day practical scenario, a strong API management
platform is required.
This is to facilitate more advanced requirements such as security, throttling, monetization, and
analytics since it is more challenging to accomplish these features for streaming APIs rather than for
conventional REST APIs.
WSO2 API Manager provides the ability to create a streaming API from scratch or use an existing
AsyncAPI specification to create the API in the gateway and improve the quality of service.
In addition to the substantial amount of features, the user/developer experience is of great
importance since it makes the tasks more intuitive, ultimately providing new users an efficient
platform to become familiarized with the system in a short period of time.

14. APIM 4.0 & events based approach
Securing Event-Driven
APIs

15. APIM 4.0 & events based approach
Rate Limiting, Throttling
and Monetization
The definition of throttling policies should also be changed. Consider the following:
• Time-based throttling: A client can only be subscribed to the topic for a specific time. After that, the
client is disconnected from the server.
• Event count-based throttling: A client can only receive x number of total events. This also can be
combined with time-based throttling and create policies (e.g., a count of 10000 events per day).
• Backpressure-based throttling: When the client cannot handle the rate of events it receives, it
imposes stress on the gateway to deliver the messages to the client — since it is required to queue
the messages and send when the client can accept them. In these situations, the client can be
removed from the gateway, to ensure that the gateway is not affected.

16. APIM 4.0 & events based approach
Analytics
Analytics plays a vital role in any API-driven business and helps to make informed decisions, by providing details
such as the number of API consumers, most-accessed API resources, latencies, identify trends, etc. It should be a
mandatory capability supported by an API management product.
In traditional REST/SOAP APIs, an API gateway can capture information such as invoking API resources, backend
latencies, geo-locations, etc. These are basically fetched from the request/response headers.
However, when it comes to async APIs, capturing this information becomes much more complex, since there are no
HTTP requests or responses. What we do have is a set of topics and subscribers.
All the messages are sent through a separate channel (server -> client or client -> server) and the gateway should be
able to capture the required information.

17. APIM 4.0 & events based approach
Analytics
For each subscriber of the API, the gateway should capture:
1. The number of messages being pushed
2. The TPS variation overtime
3. The number of publishing errors
4. Health details about the backend (endpoint)

18. Q&A?

19. GRAZIE!!!
Prossimi appuntamenti:
9 novembre 2021 10 novembre 2021

20. Contatti
DOVE SIAMO
Milano - Torino - Padova - Roma
TELEFONO
Torino +39-011-0120371
EMAIL
wso2.sales@profesia.it
@