Re: [xml-dev] Objects at REST...

[Rick Jelliffe <rjelliffe@allette.com.au>]

Peter Hunsberger wrote:
> On Wed, Mar 12, 2008 at 7:28 AM, Andrzej Jan Taramina
> <andrzej@chaeron.com> wrote:
>   
>>  1) Objects tend to be much more fine-grained than is appropriate for
>>  distributed systems access.  I would have thought that we would have learned
>>  this from the ill-fated EJB Entity beans fiasco of a number of years ago.
>>     
But having a URL does not necessarily imply accessing it, does it?  
PRESTO is not about exposing objects, but using some basic object-y 
insights to allow systematic permanent URL formation.
>>  2) WIth objects, the tendancy will always be towards using a RPC appoach,
>>  which is not in keeping with REST principles.  Objects tend to have little
>>  "data" and many methods, while resources (in the REST sense) are the reverse,
>>  with much data and few methods. Mapping between the two concepts will be
>>  problematic.
Objects have as much or as little data as you like. In particular, for 
the kind of information PRESTO is aimed at (legislation sets),  the URL 
is hierarchical so the shorter URLs will tend to correspond to big 
objects and the terminal URLs will tend to correspond to small (nested) 
objects.

>   
>>  3) It may be rare to find a clean mapping between lower level objects and
>>  resources, without using an intermediary facade layer to bridge the two
>>  levels of abstraction, especially since most OO-based systems were not
>>  designed to be exposed as resources using REST.
>>     
And that is why the PRESTO approach is best fit. PRESTO says to name 
*everything* significant: you don't just have a URL because it 
corresponds to some entity or representation, you have it because it 
corresponds to some significant concept, in particular the information 
at some particular granularity and versioning level. The analysis causes 
the name, not the backend implementation (though the twain should meet 
if possible.)  PRESTO says you don't limit yourself to when there is a 
clean mapping: your server can return the best fit representation it can 
which may be nothing (404?)
> I think this is the real issue; you can't just go around exposing all
> objects, you are going to have to make some conscious decision on what
> to expose and pick some way of controlling that. Whether this is via a
>  facade, annotations or something as simple as hacking package names
> won't really matter, but the work will still need to be done if such
> an approach is to be successful.
>   
The issue is not whether you can expose all objects, it is how to have 
URLs for everything important in the information, regardless of its 
availability at optimal grain or format, and how to manage this.

Here is the back story: lets say the country Freedonia wants to 
investigate making all its laws available on the web, and it wants to 
encourage mashups. And it wants to use standards, good web citizenship, 
and current COTS technology. And people rarely are interested in the 
whole piece of legislation but only parts. And often the laws are only 
available as scanned images. And often the laws are not consolidated but 
scattered across multiple amending documents. 

The classic SGML solution to this is to say "Lets mark up everything!" 
(And HTML people would perhaps say "Yes, and mark it up using HTML!")  
However, for the hundreds of thousands of documents involved, only a 
very few are high-enough value to warrant marking up. And who is going 
to pay?  So in effect we have a mixed repository, and we have to cope 
with multiple content-types with incomplete interconvertability.

Now this is a niche problem, but it is not a small problems nor an 
unimportant one!  So Freedonia then says, OK, what methodology could we 
use to address this?  And then it finds...er there does not seem to be 
one. Lots of general hints along the lines "if you want X you could do Y 
of course" but nothing concisely formulated or collected...So hey PRESTO

Cheers
Rick Jelliffe