RESTful API Resources

Jason Guiditta jguiditt at redhat.com
Fri Nov 9 14:42:29 UTC 2012


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



More information about the aeolus-devel mailing list