Prev | Current Page 287 | Next

Brad Ediger

"Advanced Rails"

Not all resources are network ???retrievable???; e.g., human
beings, corporations, and bound books in a library can also be considered resources.
* http://tools.ietf.org/html/rfc2396
What Is REST? | 191
Implicit in this definition of resources is that resources have state as well (a resource
could have empty state in the degenerate case, but this is atypical). One of the constraints
that REST places on interaction with resources is that every RESTful
resource has a uniform interface. No client has ad-hoc access (read or write) to a
resource??™s state; it is internal to the resource. All access takes place by transferring
representations of the resource??™s state* back and forth via a uniform set of methods
(in our case, HTTP).
Name opacity
A controversial principle of REST is whether names should be opaque. An opaque
value, in a network protocol, is a piece of data that the recipient can remember and
Pragmatic REST
REST in Rails is a balance between theoretical purity and pragmatism. The fact is that
many browsers do not support the full set of response codes according to the HTTP
standard.
Resource creation via POST is a good example of a discrepancy. The correct response to
successful creation is a 201 Created code with a Location header pointing to the created
resource. However, most web browsers will not redirect in response to a 2xx-series
response. Rails strikes a balance.


Pages:
275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299