RESTful API Resources

Martyn Taylor mtaylor at redhat.com
Mon Nov 12 09:17:04 UTC 2012


On 11/09/2012 02:42 PM, Jason Guiditta wrote:
> 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
+1

If you really want to use a browser, then I would suggest installing a 
plugin for your browser that allow you to set HTTP Headers on requests.  
Here is one for firefox: 
https://addons.mozilla.org/en-us/firefox/addon/modify-headers/

We really do not want to modify the API for specifically supporting 
browsers.




More information about the aeolus-devel mailing list