Hi Richard,

On Sun, Dec 1, 2013 at 4:25 PM, Richard Wallis <
[log in to unmask]> wrote:

> "It's harder to implement Content Negotiation than your own API, because
> you
> get to define your own API whereas you have to follow someone else's rules"
> Don't wish your implementation problems on the consumers of your data.
> There are [you would hope] far more of them than of you ;-)

Content-negotiation is an already established mechanism - why invent a
> new, and different, one just for *your* data?
>

I should have been clearer here that I was responding to the original blog
post.  I'm not advocating arbitrary APIs, but instead just to use link
headers between the different representations.

The advantages are that the caching issues (both browser and intermediate
caches) go away as the content is static, you don't need to invent a way to
find out which formats are available (eg no arbitrary content in a 300
response), and you can simply publish the representations as any other
resource without server side logic to deal with conneg.

The disadvantages are ... none.  There's no invention of APIs, it's just
following a simpler route within the HTTP spec.


Put your self in the place of your consumer having to get their head
> around yet another site specific API pattern.
>

As a consumer of my own data, I would rather do a simple GET on a URI than
mess around constructing the correct Accept header.



> As to discovering then using the (currently implemented) URI returned from
> a content-negotiated call  - The standard http libraries take care of that,
> like any other http redirects (301,303, etc) plus you are protected from
> any future backend server implementation changes.
>

No they don't, as there's no way to know which representations are
available via conneg, and hence no automated way to construct the Accept
header.

Rob