Body. Why are you here? Caring for your body Diet Exercise Rest.
The Why Of REST
-
Upload
william-martinez-pomares -
Category
Technology
-
view
687 -
download
2
Transcript of 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?