Apply API Governance to RESTful Service APIs using WSO2 Governance Registry and WSO2 API Manager
7 likes•4,128 views
This document discusses applying API governance to RESTful APIs using WSO2 Governance Registry and API Manager. It promotes these products for designing, implementing, and managing APIs at design time and runtime. Key points include establishing consumer/subscriber relationships, implementing versioning, and ensuring operational governance through monitoring, analytics, and quality of service controls.
Apply API Governance to RESTful Service APIs using WSO2 Governance Registry and WSO2 API Manager
- 1. lean . enterprise . middleware Apply API Governance to RESTful Service APIs using WSO2 Governance Registry and WSO2 API Manager Chris Haddad Technology evangelism, strategy, and roadmaps Follow me @cobiacomm on Twitter Read more about our API Story at blog.cobia.net/cobiacomm http://wso2.com/products/api-manager © WSO2 2011. Not for redistribution. Commercial in Confidence.
- 2. WSO2 Carbon Enterprise Middleware Platform *
- 3. Business APIs “APIs provide a way to make resources available for internal and external partners to access information and services.”
- 4. APIs All the Way…
- 5. API Architecture An API is a business capability delivered over the Internet to internal or external consumers • Network accessible function • Available using standard web protocols • With well-defined interfaces • Designed for access by third-parties A Managed API is: • Actively advertised and subscribe-able • Exhibits high Quality of Service (QoS) • Available with Service Level Agreements (SLAs) • Secured, authenticated, authorized and protected • Monitored and monetized with analytics
- 6. Resources • Addressable Resources: • Every “object” on your network should have a unique ID. • An important aspect is that each “object” or resource has its own specific URI where it can be addressed • A Uniform, Constrained Interface. • When applying REST over HTTP, stick to the methods provided by the protocol • GET, POST, PUT, and DELETE. • These should be used properly • GET should have no side effects or change on state • PUT should update the resource “in-place” • The content-type of the resource should be useful and meaningful
- 7. REST is full of subtleties • Method Safety • GET, HEAD, OPTIONS, TRACE will not modify anything • Idempotency • PUT, DELETE, GET, HEAD can be repeated and the side-effects remain the same • Caching • Correct use of Last-Modified and ETag headers • Content-negotiation
- 8. The benefits of a well-designed REST app • Bookmarkability • Each URI really points to a unique entity • Every entity can be referenced • Multiple representations are powerful • Allowing one view of a resource for users and one for systems makes application development simpler and more logical • Having well defined links • Does improve the semantic richness of an application • By comparison WSDL is very flat and doesn’t show the links between operations and services
- 9. Hypertext as the Engine of Application State Resources are identified by URIs ↓ Clients communicate with resources via requests using a standard set of methods ↓ Requests and responses contain resource representations in formats identified by media types ↓ Responses contain URIs that link to further resources
- 11. The REST Way
- 12. How to be successful?
- 13. Business Design of the APIs • Know the consumer • Who will use the APIs (both developers and final end-user)? • What type of applications will use the APIs? • What business assets will be delivered? • Maintain Operational Control • What Quality of Service is expected? • Who can access the assets? • Remember Usability and Monetization • How will the API expose business assets? • How will you demonstrate business value via direct revenue, chargeback, or showback?
- 14. API Challenges Often difficult to offer your business capabilities as an API • Potential consumers do not trust API stability, reliability, availability, or performance • Providers have scalability concerns and lack an ability to manage consumption • Security risks prevent publishing and offering open access • Difficult to manage requirements from multiple consumers and coordinate release schedule • Inability to configure API per consumer • Business return requires API metering usage rates, and billing
- 15. Use of Registries in RestFul Architecture • Registry/Repository Aspects: • Structured Organization of Data • Dependencies – Dependency Analysis • Versioning of Assets (WADL/WSDL, Schema, Policies) • Extensible meta-model (especially your custom configurations) • Custom Properties/Meta-information • Integration/Governance Aspects: • Impact, Notification, and Change Management • Broader Lifecycle Integration • API-access to resources • Endpoint discovery
- 16. Building an Approval Model: SCXML • State Chart XML: State Machine Notation for Control Abstraction • An OASIS Standard • Embedded Apache Commons SCXML library • GUI/Tooling • IBM Rational Software Architect • SCXMLgui • WSO2 Carbon Studio – Future
- 17. API Governance Roadmap • Design Time Governance • Run-time Operational Governance
- 18. API Design Time Governance Roadmap REST Design Contract Review • Stateless • Resource-oriented URL Convention • Xlinks • Security
- 19. API Design Time Governance Roadmap Consumer / Subscriber Relationships • API Manager • Promotes available APIs • Tracks subscriptions
- 20. API Design Time Governance Roadmap API Versioning • REST URL convention • API Payload versioning • Associating API to Service
- 21. Operational Governance 21
- 22. Operational Governance 22
- 23. Operational Governance 23
- 24. Operational Governance 24
- 25. Operational Governance 25
- 26. Operational Governance 26
- 27. Operational Governance 27
- 28. Operational Governance 28
- 29. Operational Governance 29
- 30. Operational Governance 30
- 31. Follow us: http://twitter.com/#!/wso2 Follow us: Contact us: http://twitter.com/#!/wso2 http://wso2.com/contact/
- 32. lean . enterprise . middleware