3843Jot, RNA and ReST vs MoST
- Aug 4, 2003Seairth, I just took a look at your blog and your comments on Jot/ReSTful
blog architecture and at RNA <http://www.seairth.com/blog/industry/49> and
These specs strike me as excessively complex. By forcing applications
interface specifications to include both a set of verbs and the
content-types/schemas allowed w/r/t those verbs we lose all the visibility
and genericity that ReST is intended to promise.
If we had a standard mapping between HTTP methods and underlying
content-types, everything would get MUCH simpler. The most useful mapping
would be from HTTP to XML and would probably look something like this:
GET /myRSSblog returns an XML document.
POST /myRSSblog#channelId adds a new child to the XML node with that id.
GET /myRSSblog#itemId returns an XML node with that id
PUT /myRSSblog#itemId replaces the XML node with that id
DELETE /myRSSblog#itemId deletes the XML node with that id
(Style using <?xml-stylesheet type="text/xsl" href="yourstyle.xsl"?> for
your viewing pleasure.)
Now you don't need any special purpose plumbing for indexing, mapping to
directory structure, or all sorts of other annoying administrivia. If you
are maintaing a blog and you want to switch from RSS to nEcho just use an
xslt transform and update your stylesheet. No special purpose plumbing
Similarly, you can simplify the RNA spec to an addressbook/subscribers
schema and an INBOX schema. Sending messages obviously is just a POST to
an inbox, etc.
For total coverage, a wiki is also just an XML document with client-side
can even standardize the rendering by using a script-src rather than
bundling your own (it is also, therefore, more likely to be cached). The
existing wiki systems encourage proliferation of wikitext formats because
the rendering is done on the servers.
Thoughts? Any reason why things need to be more complex than this?
PS The point of my advocating Model State Transfer over Representational
State Transfer is precisely that I think ReST forces servers to implement
all sorts of special purpose plumbing to hide the data model rather than
just assuming that other agents (perhaps residing on the server) will do
data model conversions if needed. I'd like to get to get rid of
content-negotiation and get to the point where the content-type/xml-schema
of a resource is all you need to know in order to interact with it.
S. Alexander Jacobson i2x Media
1-212-787-1914 voice 1-603-288-1280 fax
--On Friday, August 01, 2003 4:07 PM -0400 Seairth Jacobs
> That's what I thought, except when I was working on Jot (my RESTful blog
> system) someone (forgot who) said that 400 indicated a problem with HTTP
> layer itself (e.g. "host" header missing in HTTP/1.1) and should not be
> used for application-level errors. Currently, I am using 403, saying
> that an invalid request entity (say, a non-well-formded XML document)
> would be "forbidden". But the problem here is that the resource is what
> defines whether the request entity is valid or not (even the
> well-formedness of an XML document), so in *some* sense, a bad request
> entity "conflicts" with the resource.
> So, supposing that 409 was the correct response to use, then what is 403
> for? About the only example I could come up with was one mirroring a
> filesystem operation. Suppose you have a resource that is marked
> "read-only". An attempt to PUT to that resource may be valid if it were
> not read-only, but otherwise would return a 403. This is not a conflict,
> necessarily (though I could see it rephrased that way), and therefore not
> appropriate for a 409 response.
> Seairth Jacobs
> From: "Mark Baker" <distobj@...>
>> On Thu, Jul 31, 2003 at 09:11:23AM -0400, Seairth Jacobs wrote:
>> > Suppose an application detects a problem with the request entity.
> Should a
>> > 403 (forbidden) or a 409 (conflict) be returned?
>> I'd use 400. Neither 403 nor 409 seem relevant.
> To unsubscribe from this group, send an email to:
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
- << Previous post in topic Next post in topic >>