SOA in the API World - Facades, Transactions, Stateless Services Presentation Transcript
SOA in the API World –Facades, Transactions, Stateless Services . . .Apigee@apigeeBrian Pagano@brianpaganoGreg Brail@gbrail
@brianpaganoBrian Pagano@gbrailGreg Brail
SOA’s Adventures in API-Land - RecapServices? 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
Previously onSOA’s Adventures inAPI-Land…
Let’s make sure we’re all talking about the same thing.And let’s only talk about the core principles of SOA, notthe cruft that vendors have added on.Some product features have started to be thought of asnecessary for SOA.SOA recap
But SOA is about Service Oriented Architecture.Services are good.This taps into the deeper philosophy of breakingdown problems into components.Components are good.
A service oriented architecture might include,but does not require:• Heavyweight contracts• Service registries• Dynamic discoveryThese are product “features”.
Services? I’ve GotServices
You’ve got servicesNow you need to design a Facade
Avoid the forklift anti-pattern
What are your service consumers using?(Customers, partners, …)
What are your company goals for this API?revenue, reach, holding market share, re-using existing assets
Design a single, RESTful façade that looksoutside-inDon’t expose implementation complexity
What types of things would you not wantto do in a proxy?
Do I Make My ServicesStateless?
Yes. Make your services stateless.Unless you have a good reason not to.
But, what do we mean by “stateless”?State can be either data entity state or session/activitystate.
A stateless service never holds data or business domainstate.A stateless service minimizes holding any activity orprocessing state information. (Session data is especiallybad)
Consider a shopping cart:A. The client maintains the state and sends the whole thingback and forth every timeor:B. The server maintains the cart in memory via a temporary“session ID”, and the server empties the cart after someinactivityor:B. The server maintains the cart in a database via a permanent“shopping cart ID”
Plan A: Requiring the client to maintain all state – isimpracticalPlan C : Storing the state in a database – gives thedeveloper what they expect, and gives businessbenefits tooButPlan B: A “session” – was popular in the Web 1.0 erabut is unnecessary in today’s world of scalable andavailable databases
How To DesignInternal APIs
NoAre Internal APIs Just SOA?
Internal APIs are APIs which are not exposed tothe outside world.SOA is SOALet’s keep these things straight.
Design internal APIs with the same level ofconsumability as you would an externally-facing API.
Why should you use APIs rather than SOA as themodel for your internal services? You will want to use the same services for both mobile appsand your web apps You don’t know what kinds of device technology your API willneed to support in the future You don’t know what kinds of web app technology yourdevelopers will want to use in the future You do know that it will all change and you will have to adaptquickly
Down the road, who knows . . .What does “internal” mean anyway?Besides, you might use them again for adifferent audience.
In SumSOA still has uses in the API worldAn API layer is critical to meet today’s businessdemandsSometimes they work well togetherExpose functionality, not systems orimplementation complexity
THANK YOUQuestions and ideas to:@firstname.lastname@example.org/group/api-craft