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
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”.
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
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