On 08/11/12 14:55 +0100, Justin Clift wrote:
On 08/11/2012, at 2:51 PM, Dmitri Dolguikh wrote:
<snip>
Some clients might be interested in using a specific version of resource
representation, others might always want to use the latest.
Sure. No argument there. :)
Ideally, if a URL is used that doesn't include the version
number it should use a sensible default (ie latest). This
enables the "user choice" thing.
Adding versioning to resource urls makes discoverability harder, and requires
the client to understand resource url format.
Conversely, having the version selector inside the content
header (instead of being part of a URL) completely removes
the choice thing pointed out above.
Note - I'm not saying it's a killer, it's just you were
asking for thoughts about it. To me, user choice is
important. It might not be for the use cases you care
about. ;)
I am not convinced 'access the api from a web browser' is much of a
use case for an api. The api really is primarily geared toward being
consumed by machines/software. Can you tell me, aside from perhaps
developer testing, why we would use the api from a web browser?
Opinion on that aside, I would also say we could easily support _both_
if we felt there was a real need for the second case, with no change
to the api itself. One way to implement this would be to have the
controller continue to use the content type, but have a middleware
dropped in from of the app that would set that content type based on
its presence or absence. If absent, then extract the version from the
url, should be pretty simple. Routes file just gets an alias (or a
few) as needed.
-j
