The Rest of REST
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