On 01/30/2010 03:10 AM, Mike Orr wrote:
> Beware of the RESTafarians.  REST solves a certain set of problems,
> and its best realization seems to be ATOM.  But the "don't use cookies
> or sessions" argument fails to provide alternatives for logging in or
> restricted access, and makes result sets needlessly cumbersome. You
> end up putting the result ID (which is really a kind of session ID) in
> the URL. Or you transmit the whole data to the client and back through
> request variables, which is unfeasable with large data sets. And it's
> impossible if the client shouldn't actually see the raw data.  And
> having random result IDs still doesn't answer the question of whether
> the current request should have access to that result set.  So
> complete statelessness is impossible or at least unreasonably
> cumbersome.
>   

The sessions argument is often misunderstood, imho. The way I see it,
Fielding proposed it as a guide primarily to allow scalability.
Conveying as much information as possible into the HTTP protocol itself
-- as opposed to application protocol present in the request content --
is actually beneficial on many levels, for example it allows data
partitioning on the HTTP layer, before the request even reaches the
application for processing. Which, in turn, facilitates scalability.

However cookies are part of HTTP. They do not necessarily contain
application state. A session, for that matter, need not contain
application state, but client state validated server-side. Or temporary
state of data behind "regular" URIs. In short: it's a matter of how you
observe it.

Traditionally, session data is kept in files local to the server. That
is not scalable, I agree. But move it to a memcached cluster and it
becomes scalable. And at that point, it becomes no different than the
"regular" data behind URIs, which is, in order to be scalable, also in a
distributed storage container, a.k.a a database cluster.

If scalability is the only concern, then, the session data observed as
temporary resources which only particular clients should interact with
is fully RESTful. If purism and strict following of Fielding's rules is
of concern, then RESTful application can never be anything other than
simple public services where security is not an issue.


> I also notice that all of the most popular social networks abuse query
> strings horribly, worse than any of us would ever do, yet that hasn't
> caused the sites to crash or their users to boycott them because their
> URLs are bad.  So REST is not necessary to make the world go round and
> the sun come up.
>   

In REST the URIs are "opaque", as they say. That means that the URI has
no meaning to the client other than being a unique ID for a resource. It
can be called /page/view/123, or /asdkjh45kua8kr. The theory here states
that resources should link between themselves. A "pure" RESTful client
should not have to know how to construct the URI, but the result set
should contain enough URIs for it to function properly.

When the client creates a resource, the RESTful response should say 201
and provide a link to it, not just the primary key for client to
construct the link. And that satisfies the "self-descriptiveness"
requirement of REST. With that, any client that understands HTTP can
come along, create a resource and will understand what 201 + Location
means, because it is inherent to HTTP.

REST makes a point here that apps should not reinvent the wheel with a
protocol built additionally to the HTTP itself, if HTTP itself can carry
out the action. I agree with the not inventing the wheel thing, but I
also understand there are situations where you can't just follow "pure"
REST.


> Still, REST  is a good ideal, and it's worth moving closer to it when
> feasable. But its biggest advantage is for noninteractive clients
> which don't want to know the particular site's idiosyncracies.  Its
> benefit to interactive sites is less certain, especially those that
> are heavy on user accounts, result sets, and shopping carts.
>   

Agreed. :)


Vlad



-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Reply via email to