What about using extensions to specify the desired behaviour?
This could look as follows:
POST to /foo -> 200 OK and a XHTML representation
POST to /foo.html -> 200 OK and a XHTML representation
POST to /foo.xml -> correct response codes and a
XML
representation
POST to /foo.json -> correct response codes and a JSON
representation
that's even better. we once though about doing it like this, but i
can't remember why we didn't.
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.
I'd like to reduce the coupling between client and server assumptions.
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.
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"). 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.
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.
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.
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.
....Roy
