On Feb 11, 2010, at 10:05 AM, Jan Algermissen wrote:
>
> On Feb 11, 2010, at 9:58 AM, Paul Sandoz wrote:
>
>> On Feb 10, 2010, at 11:10 PM, Jan Algermissen wrote:
>>>
>>>>
>>>>> if you write clients that rely on any kind of expectation about
>>>>> the representations
>>>>
>>>> I don't believe this is realistic. If a client states to the
>>>> server that it Accepts a certain type he either gets the correct
>>>> representation or an error
>>>
>>> Yes. But if you code the client with the assumption that certain
>>> links will definitely be present in the response the client is not
>>> doing REST. Clients must react on what they are being sent (react
>>> on the state they are being put into by the server) and try to
>>> persue their goal from there.
>>>
>>
>> A service will document the supported media types, link types and a
>> root (bootstrap) URI. This is the hypermedia contract that clients
>> bind to. And this is what machine-based clients will program to.
>>
>
> Good - that looks like it matches what I wrote in my (long) response
> to Marc. Do you agree?
>
I have not read it yet :-) but given what you say above i assume we
probably mostly agree :-)
Embedding a related response to another email:
On Feb 11, 2010, at 1:05 AM, Jan Algermissen wrote:
> Unless the link was mandatory part of any representation of that
> media type. (Which is a vary rare thing in media type specs and
> probably bad media type design).
Consider, for the sake of argument, a purchase order XML document. It
has a structure and that structure needs to be well-defined and
documented so clients can process it reliably, part of that structure
may state that a link of a certain type may occur in the following
XPath location(s) and that link type defines how to make a payment. In
the future the documentation may specify additional links at certain
locations of certain types to, say, make different forms of payment.
Machine-based clients can then reliably code to the media types and
link types, and evolve the code as the server extends its features. So
I assert that for machine-to-machine communication such specification
of links in representations of media types is rather important.
------
What i would like to do is evolve the current proxy-based approach to
better focus on media and link types proxies (as well as perhaps a
more general builder API approach too), the proxy approach has
advantages for tooling (which goes down well in the enterprise).
The current approach focuses on a model supported by one or more media
types but the controller has all possible (specified) link types
whether valid or not for a certain application states. You can loosely
think of the controller interface as a hypermedia contract supplied by
the server, or developed by reading media type and link type
documentation.
Paul.