[MOBY-l] Re: MOBY and the "REST/SOAP" debate

[Andrew D. Farmer]

Hi Lincoln-

> Alas, the common practice of POSTing form data to a CGI script is not RESTful
> because:
>
> 	1) it is not performing an update operation, but really performing a get
> 	2) it cannot be correctly cached by caching proxies
> 	3) it is not stable nor unique; the same POST may result in a different
> 		 document each time it is executed
>
> Indeed, POST was misused almost from day one.  In the original documentation,
> POST was described as creating a "subdocument" below a URL, and was designed
> with the posting of news article in mind.

Agreed. I'm certainly not suggesting that we turn the project into
a campaign to get people to redesign their websites "correctly".
But I do think that insofar as the debate relates to the differences
between "closed-world" and "open-world" problem spaces, it seems
worth thinking about where we feel MOBY falls in this spectrum and
what that may imply in terms of criteria such as you have outlined
below.

>
> Actually, the debate is between the document-centric mindset of the hypertext
> and hyperpublishing communites, and the call-centric mindest of the remote
> procedure call community.  From my point of view, the hard part is agreeing
> on a set of data formats that correctly balance these criteria:
>
> 	- general:  They will satisfy the needs of at least two research groups.
> 	- extensible: Other research groups can extend them to meet their needs
> 		without breaking their utility to others.
> 	- modular: More complex formats can be built up from simpler ones in
> 		Leggo fashion.
>
> If we have the data formats in hand, it doesn't matter whether we fetch them
> by GETing or URL or POSTing a SOAP message.

I also agree that the representation of the data itself is a more fundamental
issue than the details of how one obtains that data (and I would be happy
to focus in on this for starters).

On the other hand, I do see it as important to think about
the "data transformation" aspects of the system, i.e. the services, and what
the implications are in terms of thinking of this in call-centric, API-like
ways (whether this is an API implemented in URL parameters or SOAP message
structures) or document-centric, "resource-linking" ways. Both approaches
have their merits, and I'm just trying to get a better sense for what
our criteria are in this arena. Hopefully some of this will come out of the
use cases discussions...