Basing the choice of representation on either URI extensions or Accept header content
negotiation is a valid decision. They each have their benefits and drawbacks, and
Rails supports both.
Statelessness
At the network level, HTTPis a stateless protocol. Each client/server interaction
repeats some information on each connection to the server. This costs some redundancy,
but it pays off in other areas such as scalability. By definition, Fielding??™s REST
is always stateless. The interaction between client and server carries no state at lower
or higher levels.
However, there is a difference between resource state and application state.
Resource state is the internal state that all nontrivial resources carry, and it is essential
to a web application. Examples of resource state would include the changes
made to a hosted document or the content of a to-do list; without this state, there
would be no application.
On the other hand, application state (also called session state) is the state of the client??™s
interaction with the server. Application state tracks a user or client??™s progress
through an application. Keeping this state on the server violates REST principles as it
breaks addressability. An implication of REST is that the representation retrieved
from a resource should depend only on that resource??™s state and the client??™s request.
If the server presents a different representation for the same URI based on the path
that the client took to get to that URI, then the URI loses its addressability.
Pages:
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306