Re: Is it correct to respond with partial representation for low capabilities media-types?

Jan,

thanks for sharing such an interesting point of view.

On Fri, Jun 15, 2012 at 5:56 PM, Jan Algermissen
<[email protected]> wrote:
> You can reformulate a bit and ask: "Given the usual flexibility (optionality of most elements) in well designed media types, how does a server developer know what a correct response body looks like. An Atom <feed/> is a correct response from the POV of the media type spec, but we would consider a blog server to be broken if it responded like this all the time.

I also consider that it is inappropriate to send text/html to command
line clients. I see it often in tutorials.

> Looking a the application the client intends to create (the use case realized by the user agent) is not an option because in a RESTful system the server does not (and must not) know the application the client is trying to walk through.

I guess that it comes from the stateless constraint?

> All the server developer really has is the media type spec of the media type it is going to serve.

There is also rfc5988 which provides link relations "outside" a media-types.

> The solution to the 'problem' is that the server developer's task is not to implement something useless, but to expose the capabilities of the server side component in a way that provides a benefit to the client, in a way that is useful. You could add: in a way that maximizes re-usability.

I have face limitations when thinking of re-usability. My first
reaction is to modified my original ideas by bowing to what the
standards and protocol can do well for me. But that is a matter of
philosophy.

--Philippe