Uploaded byBishoy Demian
API as-a-Product with Azure API Management (APIM)
The document discusses the concept of APIs as a product, focusing on their growth and the importance of community-driven development. It outlines key components of Azure API Management, including management policies, analytics, and security models. It also highlights the pros and cons of the product while pointing to a future roadmap.
More Related Content
Similar to API as-a-Product with Azure API Management (APIM)
API as-a-Product with Azure API Management (APIM)
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8. Growth in APIs2005 – to - 2013 Source: Programmable Web
- 9. “ ” UI/UX paradigms willcome and disappear. APIs are here to stay!
- 12.
- 13.
- 15. Azure API Management(APIM)
- 16.
- 17. Building Blocks APIs ProductsPolicies Analytics Security
- 18. APIs Import: WADL/Swagger Configure: URL & operations Secure: credentials & authorization Track: Issues & Client Applications
- 19. Products Visibility: usergroups Control: Subscriptions Enforce: Terms of Service
- 20. Policies Scoped Inherited XML documents C# expressions Context included
- 21.
- 22. Analytics Usage: Location,Bandwidth, Calls Health: Errors, Cache, Latency Activity: By Developers, Products, Subscriptions, APIs, & Operations
- 23.
- 24. Security Model Identity AuthenticationAuthorisation
- 25. Identity Providers Enterprise:Azure Active Directory Social: Facebook, Google, Twitter Built-in: Username & Password Custom: Delegation
- 27.
- 28. Building Blocks Docs SignupApps Issues
- 31. Conclusions Pros Cross-cutting concernsdone 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
- 32. What’s next? ProductRoadmap http://aka.ms/ApimRoadmap
- 33.
Editor's Notes
- #11 IoT is driving unprecedented growth in API production and consumption. It is very obvious why.
- #12 Is your project and “App”, a “System”, or a “Platform”?
- #15 API Management provides a simple one-stop solution for the cross-cutting concerns when publishing APIs.
- #16 API Management has 3 main components: Developer Portal Gateway Publisher Portal
- #18 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)
- #19 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)
- #20 Products allow you to: Grant/deny access to user groups Require a subscription Enforce subscription approval Users must accept terms of service
- #21 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…
- #22 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
- #23 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?
- #24 This is a simple ”Usage” dashboard.
- #25 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.)
- #26 Azure AD B2C behind the scenes. Quite capable of handling external users (v.s. plain Azure/AD)
- #29 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)