Re: REST and HTTP Update

On 10/6/09 12:18 PM, "Steve Harris" <steve.harris@garlik.com> wrote:
> I share Kjetil's concerns about the REST thing, but on the other hand
> I think it's a very important aspect of the protocol.
> 
> An alternative, which I believe to be RESTful is to target requests to
> 
>    $endpoint + uriencode($graph)
> 
> This is compatible with PUT and POST semantics, and I believe that it
> conforms to REST ideals, though that may be arguable.

This is the problem and the point where the question of what is RESTful
drifts from best practice to philosophy IMHO.  .

Consider the 'opacity axiom' [1] which (I believe) is often associated with
claims that URIs which require an intermediate agent to parse their lexical
form violates a best practice:

[[[
The only thing you can use an identifier for is to refer to an object. When
you are not dereferencing, you should not look at the contents of the URI
string to gain other information.
]]]

However, by my reading, there is nothing in the REST style document that
rules this out.  The section on Resource and Resource identifiers only talks
about resources and the ability to name them:

[[[
REST uses a resource identifier to identify the particular resource involved
in an interaction between components.
]]] 5.2.1.1 Resources and Resource Identifiers

In addition, WRT the 'opacity axiom', query strings seem [1] to be
considered an exception (at least for the client and target server):

[[[
Query strings are clearly not opaque to the client. However, they should be
opaque to (for example) proxies.
]]]

So, this suggests (perhaps) that the better route would be to use a query
string instead.  But, again, the chapter on REST doesn't seem to have
anything very specific to say about this.

In my estimation, if the data model is clear about what such encoded URIs
identify, then we should be fine.  And since a resource can be anything,
this is not a hard requirement.  In addition, it brings clarity to the
protocol model about the components, their roles, identities etc.

The only other issue, I can see WRT the REST style has to do with caching:

[[[
If a response is cacheable, then a client cache is given the right to reuse
that response data for later, equivalent requests [..]

The advantage of adding cache constraints is that they have the potential to
partially or completely eliminate some interactions, improving efficiency,
scalability, and user-perceived performance by reducing the average latency
of a series of interactions.
]]] 5.1.4 Cache

So the question here is, given your example, can the user expect that if the
following requests are sent:

1) PUT http://localhost:8080/data/http%3A%2F%2Fexample.com%2Fdata.rdf
2) GET http://localhost:8080/data/http%3A%2F%2Fexample.com%2Fdata.rdf
3) GET http://localhost:8080/data/http%3A%2F%2Fexample.com%2Fdata.rdf

Where the third GET is conditional, will we have desired effect? I.e., will
the server return a 304 (Not Modified) if the RDF graph with the URI
http://example.com/data.rdf has not changed since the second request? Does
encoding the graph URI as a query string instead of as part of the path make
a difference?  

REST allows [2] resources to have many identifiers (though it frowns upon
these identifiers changing over time).  This is why one possible
interpretation of using a query string or path to encode the URI of a graph
is that it is a different identifier for the same resource (represented by
an RDF graph at the server).

If you peruse popular REST lore, you find discussion threads [3] that show
that it is still an open question whether decoding part of the URI of a
request in order to determine what is being addressed is a bad thing.

>From an engineering perspective, I think the question regarding the ability
to cache is the more relevant one.  I don't know of any other design
principle that can be reasonably stated as the reason why using a query
parameter (or part of the path) to provide the URI of an RDF graph to
manipulate (via its representations) is a bad thing.

[1] http://www.w3.org/DesignIssues/Axioms#opaque
[2] 
http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_2
[3] http://rest.blueoxen.net/cgi-bin/wiki.pl?OpacityForTheStupid



===================================

P Please consider the environment before printing this e-mail

Cleveland Clinic is ranked one of the top hospitals
in America by U.S. News & World Report (2008).  
Visit us online at http://www.clevelandclinic.org for
a complete listing of our services, staff and
locations.


Confidentiality Note:  This message is intended for use
only by the individual or entity to which it is addressed
and may contain information that is privileged,
confidential, and exempt from disclosure under applicable
law.  If the reader of this message is not the intended
recipient or the employee or agent responsible for
delivering the message to the intended recipient, you are
hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  If
you have received this communication in error,  please
contact the sender immediately and destroy the material in
its entirety, whether electronic or hard copy.  Thank you.

Received on Tuesday, 6 October 2009 20:27:30 UTC