1. SOA in the API World –
Facades, Transactions, Stateless Services . . .
Apigee
@apigee
Brian Pagano
@brianpagano
Greg Brail
@gbrail

2. groups.google.com/group/api-craft

3. youtube.com/apigee

4. slideshare.net/apigee

5. @brianpagano
Brian Pagano
@gbrail
Greg Brail

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

11. Services? I’ve Got
Services

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.

20. Layers:
Separation of Responsibility

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

38. groups.google.com/group/api-craft

39. THANK YOU
Questions and ideas to:
@brianpagano
@gbrail
groups.google.com/group/api-craft