Hacker News new | past | comments | ask | show | jobs | submit login

You've changed my example considerably. /orders/groupByCustomer and /orders/groupByDate have the exact same data. The only difference here is representation.

I would expect that API changes from version 1 to version 2 to often have even more differences than above. They may support different methods, may expose different sets of data, etc. There's no reason why they have to be thought of the same resource.

As for your thought experiment, why not have a version-independent URI that points to the latest version? I don't even understand this whole representation-neutral link - you're going to pick one representation or another. Either the client has to give the version information in a header or an URI. Header manipulation is much harder to deal with in practice and isn't easily supported by every client.




I don't think I've changed your example, I just don't agree with this:

>/orders/groupByCustomer and /orders/groupByDate have the exact same data. The only difference here is representation.

Those are two different resources (made plain within the context of my approach by the fact that they have two different URLs). Those resources are ordered collections. They contain the same totality of resources within them, but ordered collections are not semantically equal if the order is different. Therefore I argue those are two distinct collection resources. The fact that they both contain the same resources is irrelevant because the ordering is central to the identity of the resource here.

The URL is not the representation no matter how you look at it [1]. `/orders/groupByCustomer` identifies a resource which could, for example, give you an XML representation, a JSON representation, a PDF representation, etc., depending on content negotiation.

An API change which introduces different methods and data is fine. A resource returned under the new version will expose that, old versions won't see it. There's no reason why the resources can't be the same across versions, but maybe a request for v2 of Customer returns a zip code now and v1 doesn't. Still the same Customer and you have one URL for it.

As for a version-independent URI that points to the latest version (assuming no version in the header), the argument made elsewhere here is that it can break clients that use it when the API is changed.

> Header manipulation is much harder to deal with in practice and isn't easily supported by every client.

I don't think it's that much harder. Granted, if you're dealing with existing clients that only support a small subset of HTTP your choice of style might be made for you. If I'm designing a brand-new API I think I'd be inclined to say "it's 2012 and this is an HTTP service, deal with it".

PS, Thanks for the interesting discussion. It's definitely making me think this through more deeply than I have in the past.

[1] http://en.wikipedia.org/wiki/Representational_state_transfer...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: