by Roy T. Fielding
REST – Representational State Transfer
. principle design
. architectural properties
. constrains that induce properties
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?
(When Tim Berners Lee talks about web, he’s most closely talking about the Information point of view)
changes all the time
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
aka, must be SCALABLE, EVOLVABLE, VISIBLE AND RELIABLE
Style = nil
starting from a situation of no constraints
Style += client/server
apply separation of concerns: client-server
style += stateless
add optional non-shared caching
style += uniform interface
apply generality: uniform interface constraint
style += layered system
apply info hiding: layered system constraints
finally allow code-on-demand (apple/js)
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
HYPERTEXT AS THE ENGINE OF THE APPLICATION STATE!
minimizes coupling to enable evolution
… partial failure conditions
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