The Why Of REST

The Why ofREST

William Martínez PomaresArchitect and R&D ManagerAvantica Technologies [email protected]

Who Am I and Why I’m Here?

Agenda

REST What?

Application Types

The Constrain Trade-off

SOA Match Up

Suitability

NO, REST is not…

RPC API

URI W.S.

PROTOCOL!

“An RPC protocol running over SOAP …”Charlie Kaufman and Ramanathan Venkatapathy - Windows Azure™

Security Overview

YES, REST is….

“…architectural style for distributed hypermedia systems …”Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software Architectures, 5

“to minimize latency and network communication, while at the same time maximizing the independence and scalability of

component implementations”Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software Architectures, 5

Styling Styles

STYLE DEFINITION

Name Context Forces Problem Solution Consequences

STYLE REST’S STYLE

“An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.”Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software Architectures, 1.5

Play Analogy

Application Types

Distributed

Networked

Integrated

Distributed Application

Part 1

Part 2

Part 3

oApplication as a Wholeo Tight connectionsoHigh speed communicationo Strong couplingoReuse of Parts Optional

Networked Application

Node 1

Node 2

Node 3

Node 4

Node 5

Node 6

oApplication as a Composition of Nodes

oWeak couplingoHigh cost

communicationoUser aware of

compositionoReuse of Parts is

common

Integrated Application

App 1

App 2

App 3

oApplication as an Integration of Whole Applications

o Standard Interfaceso Low frequency of

interactionoHigher level processesoReuse of Parts is ruleo Large distribution

The …ilities

Performance

Network

Latency

Scalability

Anarchic

Independent

Simplicity

Separation

Concerns

Principle of

Generality

The …ilities

Modifiability

Evolvability/Extensibility

Customizability/

Configurability

Reusability

Visibility

Monitor

Mediate

Security

Portability

Standards

Mobility

Reliability

Redundancy

Fail safe

Client Server

Server

Client

• Separation of Concerns• Improve Portability of UI• Scalability per simple

server components• Independent evolution

Client Server

Server

Client

• Indirect cost of communication

• Concept degraded to hardware view

• Interaction Model may confuse Messaging with RPC

CS + Stateless Communication

Server

Client

• No context in server, session in client

• All info needed is in message• Visibility: For Monitoring• Reliability: Partial recovery• Scalability: No server stored

session

CS + Stateless Communication

Server

Client

• Decrease of performance due to increase on communication payload

• Takes away application control from server and places it into clients.

CSSC + Cache

Server

Client

• Improves performance by decreasing interactions

• Reduces average latency.• Reduces processing on

server by reusing results of processed data.

• Can be multilevel

CSSC + Cache

Server

Client

• Decrease of Reliability: Cached data may not be recently updated

• Implementation and storage cost

• Requires client awareness

CSSCC + Uniform Interface

Server

Client

Server

• Principle of Generality on Interface

• Simple Architecture, better visibility

• Decoupling. • Adds Independent

Evolvability.

CSSCC + Uniform Interface

Server

Client

Server

• Degrades Efficiency• Impedance Mismatch since

information is transferred in uniform format rather than most suitable.

• May add processing cost due to transformation

• Reduces visibility on Interface

Uniform Interface: REST Case

Optimized for Large Grain Hypermedia Transfer

Identifiable Resource concept Manipulation of resources by

representations Self-descriptive messages Hypermedia as the engine of application

state

The SOA Case

Legacy Heterogeneous Complex Imperfect RedundantBusiness service, process

oriented

Nicolai M. Josuttis, SOA in Practice, OREILLY

Large Distributed Systems

SOA – Process Oriented

Messaging: Send data to a service for processing. RPC?

No operation in protocol Business as a process, not as data Processes as resources Discoverable by repository,

centralized No flow control. External or out of

band Business semantics

REST – Hypermedia Oriented

Messaging: Send/Receive representation. No RPC.

Finite Operation set in protocol Not about business Datum as resources Discoverable by link, distributed Hypermedia as the State Engine Mixed semantics

SOA – REST Match Up

Different types of applications REST as Special Service construction

architecture Large distributed data Hypermedia related or Insensible to format

transformation. Relaxed Security Independent evolution requirement Non processing intensive Non sensitive to performance hits, cacheable.

QUESTIONS?