Apigee@apigee

Santanu Dey@Santanu_Dey

Essential API Facade Patterns

Episode 3 – One Phase to Two Phase Conversion

groups.google.com/group/api-craft

slideshare.net/apigee

youtube.com/apigee

@Santanu_DeySantanu Dey

Episode 1Composition

Episode 2Session Management

Episode 3One Phase to Two Phase Conversion

Episode 4Synchronous to Asynchronous

Webcast Series: API Facade Patterns

Problem

Solution

Benefits

Considerations

Episode 3 : One-Phase to Two-Phase Conversion

How to expose a single phase API out of a two phase API

To enable API teams and app developers to implement and improve their API designs and apps

Problem

From the point of view of the API provider, how to expose a single phase API out of a two phase API

Problem

One Phase Consumer

Two Phase Provider

1

2

What is a Two Phase Interface?

First Phase – Prepare (or Vote)

Tx CoordinatorParticipating Resource 2

Participating Resource 3

Participating Resource 1prepare

prepare

prepare

Second Phase - Commit

Tx CoordinatorParticipating Resource 2

Participating Resource 3

Participating Resource 1

commit

commit

commit

Two phase commit works well for server-side distributed architecture

Not such a good idea for an app to consume a two-phase API

AppService

Provider

commit

prepare

Transaction reliability is seldom a requirement for a JavaScript plugin or an app

Making the app a transaction coordinator is asking the developer to do too much

- to think about roll back, compensation etc.

-device runtime not well suited for heavy programming logic

Problems with Service Composition on Device

“chatty service” anti-pattern – multiple callouts from client app to multi services

Client

API Provider

1. Get user attributes

2. Get recommended topics

3. Get recommended books

Network connection, negotiate security, data format & parsing

Problems with Service Composition on Device

Client

API Provider

1. Get user attributes

2. Get recommended topics

3. Get recommended books

Network connection, negotiate security, data format & parsing

Heavy data usageToo many network calls

Battery drainPerformance

Solution

The solution is to introduce an API Façade in the middle which can handle the conversion

One Phase to Two Phase Conversion using API Façade

One Phase Consumer

Two Phase Provider

1

2

One Phase to Two Phase Conversion using API Façade

One Phase Consumer

Two Phase Provider

1

2

/reserve/payment

One Phase to Two Phase Conversion using API Façade

One Phase Consumer

Two Phase Provider

1

2

/payment

Warning! UML Ahead

If I am missing something, please let me know, but for now I consider ”REST transaction" to be an oxymoron.

- Roy Fielding

Example of the API Façade

Backend Server

API Façade

Existing Capabilities

API Exposure &

Mgmt.

App relies on REST

Benefits

Re-use existing enterprise backend

The client app avoids complexities like managing transactions = Lovable API

One Phase Consumer

Two Phase Provider

1

2

Two Phase Provider

1

2

Distributed Transaction Management

Resource states do not need to be maintained

Other Considerations

What is the trade-off?

Ability to coordinate distributed transaction from the client

Is it Possible to Expose Two-Phase API in REST?

POST /transfer/transaction{”from":”account1”, ”to”:”account2”, "amount":100}

Response:{"id":"/transfer/transaction/123", "state":”started", blah blah}

PUT /transfer/transaction/123{"id":"/transfer/transaction/123", "state":"committed", ...}

Response:{"id":"/transfer/transaction/123", "state":”comitted", blah blah}

Here is an Example

Questions?

THANK YOUSubscribe to API webcasts at:

youtube.com/apigee

Apigee@apigee

THANK YOUQuestions and ideas to:

groups.google.com/group/api-craft

Apigee@apigee

THANK YOUContact me at:

@Santanu_Deysdey@apigee.com

Apigee@apigee