On Sat, 2006-09-30 at 10:02 +0200, Stefan Tilkov wrote:
> On Sep 30, 2006, at 9:00 AM, Benjamin Carlyle wrote:
> > Well, you aren't really being RESTful unless your content type is
> > standard.
> Mark made this argument to me as well (http://www.infoq.com/articles/
> mark-baker-REST), and it still leaves me puzzled. If this is really
> accepted common wisdom, almost all examples of RESTful apps I'm aware
> of, and most articles (including e.g. the excellent one at http://
> www.xml.com/pub/a/2004/12/01/restful-web.html from Joe Gregorio) do
> not, in fact, describe RESTful applications.
Agreed. The most precient example of a RESTful application at the moment
is called the world-wide-web. If you have to write new client-side
software to deal with your new server-side software, you have failed the
REST test. A generic browser with sufficient knowledge of standard verbs
and content types should be able to access and interact with your
RESTful service. Special-purpose clients can still be written, but they
should never be required.
> Or should we view REST as an ideal and a RESTful app as one that
> tries to come as close to it as possible?
We should leverage, replicate or integrate with the success of
microformats in defining standard content types. Tantek and his
collaborators have been very successful in developing a model for
standard-building and also the practice of standard building. The model
essentially amounts to:
* Looking for existing formats that overlap the subject area you are
attempting to standardise
* Looking for already-published data (or perhaps software that already
produces data) linked to the subject area
Find the closest match, and use that as your starting point. New ideas
or requirements are largely ignored. Cover the 80% case and evolve
rather than trying to dot every "i" all at once. Sort out an namespace
clashes with previously-ratified formats to ensure that terms line up as
much as possible and that namespaces do not have to be used. Allow
extensions to occur in the wild without forcing them into their own
Given the success that microformats have already achieved, I would
suggest that directly copying their standards back into the XML world
would also be a viable standardisation mechanism. I have certainly been
using them myself as the guideposts to content-type development when
humans are not involved in a conversation.
I don't know whether pure machine-to-machine information transfer is at
the tipping point that microformats have achieved yet. Microformats can
survey a huge amount of html-encoded information and genuine experince
in determining which existing formats are useful and which are chaff. To
develop pure machine-oriented formats in the same way we would need a
large base of nearly-restful services to look for commonality between.
If we are at the tipping point, a wiki, mailing list, instant messaging
channel, and community champions might be enough to get things going. It
might be useful to kick off such a community for problem domains that
fall between the microformat cracks (Are there enough invoices on the
web yet for the microformats crowd to standardise the format?).
Community-driven formats are probably the only real way to develop
useful ontology through content types. As such, the nearly-RESTful
services out there are still of benefit. So long as they migrate to a
standard once the industry they are part of starts to pick up, REST will
be the ultimate outcome. This outcome also has a name: The semantic web.
RDF really isn't the cornerstone of the semantic web. RDF is too closely
aligned to artificial intelligence and high ideals as to how information
can be reasoned with generically to be really useful as an information
exchange mechanism. The semantic web is here, however, today. A content
type is an ontology, and we already have good experience with some very
popular and useful ontologies. Perhaps there are already enough web
applications today with nearly-RESTful APIs that standardisation based
on actual use may be viable.