On Fri, Nov 18, 2005 at 05:54:19PM -0600, L. Daniel Burr wrote: | Just a comment from the peanut-gallery: As a person who is currently | using web2, I want to weigh in heavily on the side of "restrict the | applications of twisted.web2 to object publishing". The way in which | web2 publishes objects fits very nicely with the way Roy Fielding | describes REST, at least insofar as my understanding of REST goes.
In Roy Felding's REST model, a Resource is a function mapping t (time) into a representation for that resource, where a representation is a set of entities (byte streams) which are logically equivalent. According to Felding, a Resource must have a semantic definition "that distinguishes one [resource] from another". In the practical implementation of his model, URIs become resource identifiers, a unique name for a given resource, and the content returned are the entities which, for all of those requesting the resource, must be logically equivalent at a particular period in time t. The fun part of Felding's model is that a Resource (at a point in time) is a _set_ of equivalent entities, where by the actual entity returned for a give request is determined by "Content Negotiation". Hence, different media types (say an XML or JSON or PNG) of a given set of information may be returned depending upon the negotiation between the client and the server. However, the semantic meaning of the actual entity returned must be equal for _all_ possible content negotiations. A Resource refers to a 'concept', rather than a particular representation of that concept at a particular point in time; but it also implies a certain amount of consistency between its representations. The particular notion of REST is that all interactions are stateless: "each request contains all of the information necessary for a connector to understand the request independent of any requests that may have preceded it". In other words, no server side state or cookies should be used. While this is great for routine operations; it falls short when doing 'authentication', which, according to the specifications themselves requires server-side state (the challenge must be remembered). Felding criticizes Cookies in his paper but does not seem to propose an alternative solution to address user authentication concerns. For most purposes, this stateless property is a fantastic goal to strive for; however, it is not and should not be a rule. While "object publishing" may support REST semantics, it is not the only possible way to be REST; and there is no reason why Twisted should require this model if it isn't absolutely necessary. | Every Resource *should* be identified by a URL, and that URL *should* | refer to one logical Resource. This is how the web works today; I for | one, hope that it continues to do so. It should be noted that Felding and most others do not require that the relation from URIs onto Resources be injective -- that is, two different URIs may (and often do) refer to the same Resource. The object publishing methodology seems to imply (or assume?) an injective relation between URIs and Resources. This is not a necessary assumption. I certainly do not suggest that the same URI should refer to two different resources; however, it is certainly valid for two _different_ URIs to refer to the same resource, and Twisted's web2 should support this methodology -- or at least be neutral towards it. | That said, I'm completely in favor of coming up with sane mechanisms for | Sessions and Auth. Changing web2 such that the a singly-rooted tree of | Resources is no longer the base metaphor should not be a requirement for | implementing Sessions and Auth. Part of the problem with Sessions (or Authentication in general) is that it requires server-side state. With the _sole_ exception of the user's identity, my application is completely stateless. However, I've yet to see a "stateless authentication" mechanism. If you have one, great! | It seems to me that you'd be much happier with a WSGI solution, wherein | you can just plug your request-processing, session-handling, foo-handling | components into the stream at appropriate places. Web2 supports WSGI | already, so that might be a better route to take. I didn't notice; but it looks like a good option. Thanks for pointing it out to me. | Then you can implement | the model that best suits your application, while leaving web2's object | publishing model intact for those of us that vastly prefer it. I have no problem with web2's object publishing mechanism; my problem is that such a system could easily be layered on-top of a simpler interface -- but it isn't. Kind Regards, Clark _______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
