Thank you for your feedback. We had noticed your commnet on
and did not knwo how to
respond to it. This is certainly the best place to discus these
The proposed protocol is actually supported by APP (Atom Publishing
Protocol). There is a service document that ought to be used by a
client to discover the links provided by the server.
The link to that document is (or ought to be :) discoverable in the
headers of the first page.
I hope this addresses your concerns.
Thanks again for your kind feedback,
> From: Mark Baker <mba...@gmail.com
> Date: Mon, 2 Jun 2008 20:31:16 -0700 (PDT)
> To: cappelaere <cappe...@gmail.com
> Subject: Re: Version 0.4
> Kudos for trying REST on for size, folks ...
> I haven't had a detailed look at the spec, but my initial scan
> identified what seems a pretty significant issue. AFAICT, you seem to
> be standardizing portions of URI names, e.g. "./workflows" or "./
> definitions". One of REST's constraints - in fact, probably it's
> single most important constraint - is called "hypermedia as the engine
> of application state", and it means that clients make progress through
> an application state machine *only* by following links provided the
> server. If a client uses a priori knowledge of the URI structure of
> the server, then that isn't REST, for the same reason that well known
> URIs like "robots.txt" and "favicon.ico" aren't REST: it dramatically
> increases coupling between client and server, preventing their
> implementations from evolving independently.
> So instead of standardizing "./workflows", instead define a document
> data element that can be used to assert that some particular URI
> identifies a workflow container, something like;
> <workflow href="http://example.com/foo/bar/my-workflow-container
> If I've misunderstood based on my incomplete review of the spec, my