REST proposal (was RE: [xdi] How to send XDI message to server?)

["Barnhill, William [USA]" <barnhill_william@bah.com>]

What I have been considering XDI REST is be REST with the following additional constraints:

1) Every URI is a URI representation of an XRI

2) Every resource representation (the HTTP body of a POST or PUT) is one of

    a) an XDI graph in an accepted XDI format, which defaults to XDI JSON and MIME type of application/json+xdi

    b) a literal in an XDI graph whose format is specified by the MIME type

3) Every operation on a resource, and every resource representation response, has an additional header $base which has a single quoted strong as its value, with that string containing a valid absolute XRI

4) As with $base, every request/response has a $lc header which specifies the link contract under which the request/response should be processed.  

5) As with $base, every request/response has a $xri header which specifies the XRI of the specific XDI message

6) XDI operations are mapped to HTTP operations as follows:
      $add  ->  HTTP POST
      $del   ->  HTTP DELETE
      $get   ->  HTTP GET
      $mod ->  HTTP PUT
      $test  ->  HTTP HEAD

 7) Any resource XRI (target, $base) may have a query string part. That query string must have a filter parameter which takes an XDI graph expression (details for another document or email) that when evaluated restricts the XDI graph returned, or operated on, to one or more sub-graphs.

This leaves Link Contract negotiation / authentication unspecified, which we'd have to fix.  Also it doesn't map XDI errors to HTTP errors, or deal with forwarding, which we'd have to fix.