SOA in the API World –Facades, Transactions, Stateless Services . . .

Apigee@apigee

Brian Pagano@brianpagano

Greg Brail@gbrail

groups.google.com/group/api-craft

youtube.com/apigee

slideshare.net/apigee

@brianpaganoBrian Pagano

@gbrailGreg Brail

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

Previously onSOA’s Adventures in API-Land…

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

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.

A service oriented architecture might include, but does not require:

• Heavyweight contracts• Service registries• Dynamic discovery

These are product “features”.

Services? I’ve Got Services

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 looks outside-in

Don’t expose implementation complexity

Transformation OnboardingProtocol Mediation

Big System

DBContent

Management SOAP JDBC

AppApp

Developer

XML

Routing Authentication Traffic Mgmt Caching Monitoring

API Facade

Be consistent

Do what developers are expecting.

Layers:Separation of Responsibility

What types of things should a proxy do?

What types of things would you not want to do in a proxy?

Do I Make My Services Stateless?

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/activity state.

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)

Consider a shopping cart:

A. The client maintains the state and sends the whole thing back and forth every timeor:

B. The server maintains the cart in memory via a temporary “session ID”, and the server empties the cart after some inactivityor:

B. The server maintains the cart in a database via a permanent “shopping cart ID”

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

How To Design Internal APIs

No

Are Internal APIs Just SOA?

Internal APIs are APIs which are not exposed to the outside world.

SOA is SOA

Let’s keep these things straight.

Design internal APIs with the same level of consumability as you would an externally-facing API.

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

Down the road, who knows . . .

What does “internal” mean anyway?

Besides, you might use them again for a different audience.

In Sum

SOA still has uses in the API worldAn API layer is critical to meet today’s business

demandsSometimes they work well togetherExpose functionality, not systems or

implementation complexity

Questions

groups.google.com/group/api-craft

THANK YOUQuestions and ideas to:

@brianpagano@gbrail

groups.google.com/group/api-craft