Loading ...
Sorry, an error occurred while loading the content.

3843Jot, RNA and ReST vs MoST

Expand Messages
  • Alex Jacobson
    Aug 4, 2003
      Seairth, 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
      <http://www.seairth.com/blog/jot/docs/6> <http://www.seairth.com/web/rna/>

      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
      required....

      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
      javascript placed in the stylesheet that does the wikitext rendering. You
      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?

      -Alex-

      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
      <seairth@...> wrote:

      > 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
      > seairth@...
      >
      > 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:
      > rest-discuss-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
    • Show all 26 messages in this topic