On Sat, Jan 30, 2010 at 4:06 AM, Haron Media <[email protected]> wrote: > > 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.
I agree with putting resource IDs into the URL rather than query parameters as much as possible. That's what I meant about social networks abusing query parameters. /photos.php?imageid=123&friendid=456&someotherid=789&sort=alpha&start=144 > 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. Well, from a machine point of view, OK. But I also think URLs should be human readable, and each component should contain the one on its right. I got those ideas from the REST literature. -- Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
