Transitions from a single App or a closed system to an open ecosystem that drives innovation and delivers value-add Apps and services for your end-users. Monetise your data with minimal hassle & cost. Reach your end-users on any platform. Enable your IoT strategy with a strong cloud-based API platform.
Using Azure API Management, you can build a modern interactive developer portal for your APIs. Learn about your API usage patterns with analytics. Secure access, and manage subscriptions with quotas and throttling.
31. Conclusions
Pros
Cross-cutting concerns done with
better consistency
Costs less $$!
Easy to use & customize
Familiar tools (Git, C#, PowerShell)
Already part of Azure
Cons
Still a new product
Some rough edges
Latency overhead
Versioning strategy missing
IoT is driving unprecedented growth in API production and consumption. It is very obvious why.
Is your project and “App”, a “System”, or a “Platform”?
API Management provides a simple one-stop solution for the cross-cutting concerns when publishing APIs.
API Management has 3 main components:
Developer Portal
Gateway
Publisher Portal
Each API refers to a back-end service that you can customize (URL mapping, query and path parameters, request/response content, caching, etc.)
Products can be Open or Protected. Protected products must be subscribed to before they can be used, while open products can be used without a subscription.
Policies can introduce some logic in how to process the API calls. Allows .Net code blocks. Provides context parameters.
Users can come from multiple identity providers (enterprise, social, and local user/pass)
Import APIs from WADL or Swagger specs
URL mappings (rewrite)
Enable/Disable caching of operations (policies have more fine-grained controls)
Configure Gateway<->API authorisation
Configure User<->API authorisation (used for interactive developer portal) .. (Oauth 2.0 & OpenID connect)
Built-in issue tracker (very simple)
Products allow you to:
Grant/deny access to user groups
Require a subscription
Enforce subscription approval
Users must accept terms of service
Scope can be per operation, API, product, a mix of all of these, or global
Encapsulated inside a very simple XML document structure (inbound, backend, outbound)
Access to Request, Response object and Product, Subscription, etc…
Built-in policies makes life easy for simple scenarios
C# code can be a very powerful tool to write advanced policies
Integration with external tools and APIs (payment gateway? Or bug tracker maybe?) with
Anyone attempted to measure an API Error rate? Latency? Cache hits? usage? How long did it take?
How do you make informed decisions on which APIs & Operations need more attention?
How do you decide which Operations in your API needs optimisation?
This is a simple ”Usage” dashboard.
Developer Authentication (uses identity)
Backend API authentication (Basic, client cert.)
Interactive API calls in developer portal require a helping hand to perform authorisation (OAuth 2.0)
Validate incoming JWT tokens (issuer, expiry, signature, etc.)
Azure AD B2C behind the scenes. Quite capable of handling external users (v.s. plain Azure/AD)
Each API refers to a back-end service that you can customize (URL mapping, query and path parameters, request/response content, caching, etc.)
Products can be Open or Protected. Protected products must be subscribed to before they can be used, while open products can be used without a subscription.
Policies can introduce some logic in how to process the API calls. Allows .Net code blocks. Provides context parameters.
Users can come from multiple identity providers (enterprise, social, and local user/pass)