SOA in the API World - Facades, Transactions, Stateless Services
Download as PPTX, PDF•6 likes•9,006 views
This document discusses best practices for designing APIs based on service-oriented architecture (SOA) principles. It recommends using a facade to expose internal services through a single RESTful API. Services should be stateless and avoid holding session data to improve scalability. Internal APIs should be designed with the same focus on usability and consumability as external APIs, even if not publicly exposed, to allow for future changes. SOA concepts like service registries are not required for APIs but breaking problems into reusable components and services is still valuable.
SOA in the API World - Facades, Transactions, Stateless Services
- 1. SOA in the API World – Facades, Transactions, Stateless Services . . . Apigee @apigee Brian Pagano @brianpagano Greg Brail @gbrail
- 6. SOA’s Adventures in API-Land - Recap Services? I’ve got services! (Designing a Façade) Layers: Separation of Responsibility (which Transactions?) Do I make my services stateless? How to design internal APIs? Overview
- 7. Previously on SOA’s Adventures in API-Land…
- 8. Let’s make sure we’re all talking about the same thing. And let’s only talk about the core principles of SOA, not the cruft that vendors have added on. Some product features have started to be thought of as necessary for SOA. SOA recap
- 9. But SOA is about Service Oriented Architecture. Services are good. This taps into the deeper philosophy of breaking down problems into components. Components are good.
- 10. A service oriented architecture might include, but does not require: • Heavyweight contracts • Service registries • Dynamic discovery These are product “features”.
- 12. You’ve got services Now you need to design a Facade
- 13. Avoid the forklift anti-pattern
- 14. What are your service consumers using? (Customers, partners, …)
- 15. What are your company goals for this API? revenue, reach, holding market share, re- using existing assets
- 16. Design a single, RESTful façade that looks outside-in Don’t expose implementation complexity
- 17. Transformation OnboardingProtocol Mediation Big System DB Content Management SOAP JDBC App App Developer XML Routing Authentication Traffic Mgmt Caching Monitoring API Facade
- 18. Be consistent
- 19. Do what developers are expecting.
- 21. What types of things should a proxy do?
- 22. What types of things would you not want to do in a proxy?
- 23. Do I Make My Services Stateless?
- 24. Yes. Make your services stateless. Unless you have a good reason not to.
- 25. But, what do we mean by “stateless”? State can be either data entity state or session/activity state.
- 26. A stateless service never holds data or business domain state. A stateless service minimizes holding any activity or processing state information. (Session data is especially bad)
- 27. Consider a shopping cart: A. The client maintains the state and sends the whole thing back and forth every time or: B. The server maintains the cart in memory via a temporary “session ID”, and the server empties the cart after some inactivity or: B. The server maintains the cart in a database via a permanent “shopping cart ID”
- 28. Plan A: Requiring the client to maintain all state – is impractical Plan C : Storing the state in a database – gives the developer what they expect, and gives business benefits too But Plan B: A “session” – was popular in the Web 1.0 era but is unnecessary in today’s world of scalable and available databases
- 29. How To Design Internal APIs
- 30. No Are Internal APIs Just SOA?
- 31. Internal APIs are APIs which are not exposed to the outside world. SOA is SOA Let’s keep these things straight.
- 32. Design internal APIs with the same level of consumability as you would an externally- facing API.
- 33. Why should you use APIs rather than SOA as the model for your internal services? You will want to use the same services for both mobile apps and your web apps You don’t know what kinds of device technology your API will need to support in the future You don’t know what kinds of web app technology your developers will want to use in the future You do know that it will all change and you will have to adapt quickly
- 34. Down the road, who knows . . . What does “internal” mean anyway? Besides, you might use them again for a different audience.
- 35. In Sum SOA still has uses in the API world An API layer is critical to meet today’s business demands Sometimes they work well together Expose functionality, not systems or implementation complexity
- 37. Questions
- 39. THANK YOU Questions and ideas to: @brianpagano @gbrail groups.google.com/group/api-craft
Editor's Notes
- #2: Creative Commons Attribution-Share Alike 3.0 United States License