by Roy T. Fielding
REST – Representational State Transfer
. principle design
. architectural properties
. constrains that induce properties
Architectural Style
a style can be applied to many architectures
an architecture can consist of many styles
design at the right level of abstraction
styles help architects communicate architecture
…
What really is the web?
browsers
servers
protocols
information **
(When Tim Berners Lee talks about web, he’s most closely talking about the Information point of view)
Web Implementation
changes all the time
Web Architecture
components
user agents
intermediates
servers
connectors
http protocol
uri
Web Requirements
low entry barrier
hypermedia user interface
simple protocols for authoring and data transfer
aka must be SIMPLE, REUSABLE and EXTENSIBLE
distributed hypermedia system
large data transfers
sensitive to user-percevied latency
aka must be DATA-DRIVEN, STREAMABLE AND CACHEABLE
simples organizational matters
anarchic scalability
fragmented change
aka, must be SCALABLE, EVOLVABLE, VISIBLE AND RELIABLE
Style = nil
starting from a situation of no constraints
www
Style += client/server
apply separation of concerns: client-server
style += stateless
add optional non-shared caching
improves efficiency
reduces latency
improves scalability
style += uniform interface
apply generality: uniform interface constraint
improves visibility
independent evolvability
decouples implementation
style += layered system
apply info hiding: layered system constraints
shared caching
improves scalability
legacy encapsulation
load balancing
REST Style
finally allow code-on-demand (apple/js)
reduces visibility
improves extensibility
REST uniform interface
important resource are identified by one resource identifier mechanism
access methods (actions) means the same for all resources (universal semantics)
resources are manipulated through the exchange of representations
self-descriptive messages
HYPERTEXT AS THE ENGINE OF THE APPLICATION STATE!
Rest Rationale
maximizes reuse
minimizes coupling to enable evolution
… partial failure conditions
… bound
simplifies, simplifies, simplifies
What’s missing from Rails
uniform method semantics?
rails support (via crub) is outstanding
but what happens when I add a new http method?
resource identifiers for important resources?
route configs are good, but code-structure dependent
URI templates would be better
resources manipulated as representations?
Rails has excellent support for alternatives data formats
… engine of application state?
… ? can it be guided by rails