The document outlines best practices for API management using WSO2 API Manager, focusing on an API-first design approach, lifecycle management, versioning services, securing APIs, rate limiting, and monitoring. It emphasizes the importance of maintaining high-quality APIs through proper design, security mechanisms, and analytics for performance tracking. Additionally, it discusses strategies for promoting APIs and ensuring scalability in a distributed architecture.

1. API Management Best Practices with WSO2
API Manager
Chanaka Fernando
WSO2 Inc

2. Agenda
● API First Designing Approach
● API Life-cycle management
● Manage services through API versioning
● Securing APIs
● API rate limiting and Throttling
● API Monitoring
● Promote, Advertise and socialize APIs
● Scaling the API Manager
2

3. API First Designing
Approach

4. 4
API Always Comes First

5. API First Designing Approach
● API Developer should have accurate API design.
- API acts as a contract between the service providers and consumers,
● Need to create new version instead of editing existing API.
● A high-quality API management solution should provide a mechanism to design
the API by considering both technical and business aspects.
- WSO2 API Manager has the capability of facilitating above both parties.
● API developers can use the API Publisher web interface of WSO2 API Manager
and Technical aspects are important to them.
● Both API consumers and service providers are interested in business aspects.
5

6. 6
● API Design - Over the wizard & with swagger
Creating APIs

7. API First Designing Approach
● API Developers and publishers should decide the visibility and subscription
availability for the API in a multi-tenant environment.
● The API visibility should be controlled over the business domains.
● WSO2 API Publisher has the capability to include API resource to manage
different endpoints.
● WSO2 API Manager also has an integrated Swagger UI to properly design the
APIs.
7

8. API First Designing Approach
Best practices while creating APIs
● Proper Naming APIs.
● Proper versioning.
● Proper HTTP methods.
● Create API for dedicated backend services.
● Consider the special behaviours of the APIs.
● Proper error handling.
8

9. API First Designing Approach
Error handling with Circuit Breaker
9

10. API Lifecycle Management

11. API Lifecycle management
● Each API has its own life cycle state.
● The developers can improve and refine the API before deploying it in production.
● The consumers can take decisions based on the API status.
● In APIM, we can identify the several API status and relevant recommendations
per each life cycle state.
Created state :
- This is the starting stage of the API.
11

12. 12
● Manage stages of an API
● Manage associated states
● Create a new version from an
existing
● Audit changes to lifecycle states
● Support for custom lifecycles
API Lifecycle Management

13. API Lifecycle management
Prototyped state-
This helps API developers to refine the API and make sure it is production ready in a
way that it is beneficial to most of the users.
Published state-
API is deployed as a production ready service. Consumers must have a valid
subscription to the API if they are interested in using the service.
Blocked state-
API developers can change the lifecycle to “Blocked”. This might be useful when there
are security issues or service violations. Once the issue is fixed, API developer can
re-publish the API. Also, it is possible to deprecate the API if needed.
13

14. API Lifecycle management
Deprecated States
The API can be “Depreciated”, If the developer needs to update
published API with latest modifications.
By deprecating the API, The developer can make allow existing APIs
to the consumer and restrict to subscribing new consumers for it.
Retired state
The final stage of the api and API is unpublished from the gateway and deleted from
the store. But still the developers can’t create a api as a same context
with the retired APIs have.
14

15. API Lifecycle management
15

16. Manage services through
API Versioning

17. Manage services through API versioning
● There may be requirements to have API modifications.
● It is not recommended to modify a published API which already has consumers.
● The best practice is to create a new version of the same API with the
update/change.
● Editing API with active subscribers will violated the business agreement
between API publisher and consumer.
● If the developer wants to update the existing API, He/She should creates a
prototype as a new version and make allow consumers to try out the the
prototype and after being maintaining both older and newer, deprecate the old
version and published the API which is in prototype status.
17

18. Manage services through API versioning
18

19. Manage services through API versioning
19

20. Manage services through API versioning
20

21. Securing APIs

22. Securing APIs
● API Security mainly based on OAuth2.
● Consumers should obtain a access tokens to consume the subscribed APIs and
It will be expired in particular time period.
● The API grant type use to authorize access to protected resources.
● WSO2 API supports four main common grant types
-Authorization code grant
-NTLM grant
-Password grant
-SAML extension grant
22

23. 23
● Protecting for applications and users
● Controlling access and entitlement with scope
● Multi-Tier subscription model
Protecting APIs

24. 24
● Encapsulate the client application
● Associates OAuth2 keys
● Support different integration
patterns for application security
through OAuth grant types
● Pre-generated access tokens for
testing
Client Application

25. Securing APIs
● The API developers can define their own custom grant type.
● The key manager handle the access tokens and It is possible to extend the key
manager in WSO2 API Manager using WSO2 Identity server as the key
manager.
● Can be configured a third party key manager.
● Can authenticate via Google or facebook.
25

26. API Rate limiting and
Throttling

27. API rate limiting
● The API rate limiting is managing traffic is important feature in real world
deployments.
● The traffic manager is responsible for
- regulating API traffic.
- making access API and applications to consumers at different
service levels.
- securing APIs against security attacks.
- process throttling policies in real time.
27

28. 28
● Tier based simple model
○ Application developer selects the tier at app registration
○ Each tier is tied to a policy that describe the quota
○ Tiers can be applied at the application, API or at the API resource level
● Advance rule based models
○ Policies containing IP conditions, message attribute based conditions,
transport header based conditions
○ Complex real time pattern based conditions
Traffic Management

29. 29
Traffic Management

30. 30
API Throttling - client view

31. 31
API Throttling - execution flow

32. API Monitoring

33. 33
● Analytics dashboard on API stats
○ API Usage / Response times
/ Backend latency /
Geo-location etc
● Stats on Applications for
application owners (subscribers)
● Stats on subscriptions
API Analytics: Batch

34. 34
● Leverages real-time analytics streaming engine
● Used for various alerting use-cases
○ Fraudulent access token usage
○ Keeping API developers alerted on backend performance issues
○ Alerting on SLA violations
○ Alerting on tier crossing for subscriptions
● Detect trends
● Detect API call sequences that needs to be blocked
● Detect non-usage scenarios
API Analytics: Realtime

35. Promote, Advertise and
socialize API

36. Promote, Advertise and Socialize API
● The API business owner can advertise, market and sell APIs as a product in
developer communities worldwide.
● Mainly these community features can be found in API Store.
● In API Store, there is a facility to search apis based on different attributes. API
name, API provider, API version, API documentation, and API status are some of
the supported search criteria.
● Rating and commenting.
● Sharing the API via social media.
● Consumers can join to forum to discuss the ideas.
36

37. Scaling the API Manager

38. Scalability
● Componentized architecture allows the API Manager to scale to higher limits
without any bottleneck
● Different components can scale at different rate
● Components can be deployed across different security zones based on the
requirements
● 1000 TPS on average with minimum HA deployment (2 node all-in-one)
38

39. 39
● Each component can be
independently scaled
● With separation of concerns, the
performance numbers are
superior than the all in one mode
Scalability
Fully Distributed Deployment with HA

40. THANK YOU
wso2.com