Hi Roy, Roy Fielding wrote: > IMO, avoiding a 201 response just because one browser doesn't support > it in a given context is wrong -- we should encourage the browser > to be fixed and use a version-specific work-around for existing users. > In most cases, browser-specific javascript or CSS is preferable to > making the server's response browser-specific. Absolutely. Actually I think there is no issue with a 201. Is someone aware of a browser issue with a 201?
> I'd like to reduce the coupling between client and server assumptions. I think this would favor a solution where the current default response (a browser/javascript friendly 200 text/html) would be deprecated (as the default) in favor of a more standards compliant solution. If I read Alex's suggestion and the consensus correctly that's exactly the proposed direction. So we would keep the "browser friendly" response around as special case for people who need to be able to interact with the current real-life browser. > I watched Michael's excellent screencasts last week and noticed many > cases where example client code is being tied directly to the server > implementation. Things like "for" loops to iterate over sets of nodes > on the client side look cool from the programmer perspective, but are > really awful from the HTTP perspective. Resources in HTTP are like > stored procedures in databases -- they should only be treated like > storage units when the user is creating a mashup of someone else's > services. The server owner (or the owner's implementation framework) > should be defining special resources for list views like index or > iteration. I see... currently we supply such a default list (actually tree) view of a resources in .json as a default sample in Sling. As a matter of fact we already allow a variety of different views that can be consumed by various client frameworks. It definitely would be desirable to come up with a more URL oriented view aswell, similar to Atom or WebDAV. (which we btw. already support over the repository) > HTTP is designed to respond with a "list of node references" when a > GET is made on a "directory", where "directory" is defined by some > pattern known only by the server (usually URIs that end in "/" or > "/index"). I see... I think we have not even considered the handling of that in sling so i think a get to /folder/ is not used yet. > Likewise, a POST to that same directory URI should > create a new node "within" that directory space and, if successful, > return 201 and the new node's URI in the Location field. IIRC, > Sling is using a path segment of "*" for that purpose. It should > be configurable. Good point... Darn, I wish I thought of that earlier. Posting to /folder/ instead of /folder/* seems even more natural. > There can also be a special resources for "all content". > For example, it used to be common to have things like > > http://example.com/foo > http://example.com/foo/ > http://example.com/foo.tar > http://example.com/foo.tar.gz > > where the first would generate a "normal" representation (like > sending the jcr:content property) or redirect to the second, the > second would provide a "directory view" of the subnodes, the > latter two would generate an tar archive on the fly, and the > last would deflate as well. Some implementations prefer to put > all of the "content" views under the parent "directory", at least > partly because it makes access control easier, but I always > preferred to think of content-containment relations as a > virtual subdirectory. Hence, every file.xml also defines a > directory of "file.xml/*" nodes ... YMMV. I think one could view our current handling of .json extensions for something like ... http://example.com/foo.x.json ... as another example of that. > None of the above is particularly RESTful in any sense -- it > is just using HTTP's hierarchical namespace. To be RESTful, we > need to ignore the client-visible implementation patterns and > replace them with links (specific references within a context > that tells the client what to expect, such as mark-up element > attributes, links with rel types, or URI templates that can be > communicated to the client). That is what Atom does, for example. > It doesn't matter what URI structure is used to relate Atom > posts to Atom feeds, since all representations are interlinked > with relation types that define the content relationships > regardless of their containment hierarchy. I see. Would it be fair to say that the containment hierarchy should be viewed as a very typical relationship and therefore could deserve a short-hand treatment, while we still want to be able to cover the more general case of a relationship between arbitrary resources. > In other words, think of a repository as a tree of content with > a nearly infinite number of potential views over that content. > Sling should automatically provide a comprehensive subset of > those views as additional resources (with access control). > Doing that with selector patterns is possible from the server > point of view, but we should not let clients depend on those > patterns. Instead, we should figure out what type of relation > applies to each view and encourage those relations to appear > as links, perhaps even generating the Link header fields. > That will enable decoupled machine traversal of the content, > which is something none of the other web frameworks do right. Excellent. I think I am very open to finding ways of interaction with the client beyond the current "containment" model exposed by the sling client library. Of course help and specific ideas would be much appreciated ;) regards, david
