Open Stack

On 06/05/2015 10:34 AM, Chris Dent wrote:
> On Fri, 5 Jun 2015, Sean Dague wrote:
> 
>> Thanks for your time,
> 
> Thanks for writing that up.
> 
> I recognize that microversions exist and are as they are so I don't
> want to derail, but my curiosity was piqued:
> 
> Riddle me this: If Microversions are kind of like content-negotiation
> (and we love content-negotiation) for APIs, why not just use content-
> negotiation instead of a header? Instead of:
> 
>    X-OpenStack-Nova-API-Version: 2.114
> 
> do (media type made up and not suggesting it as canonical):
> 
>    Accept: application/openstack-nova-api-2.114+json
> 
> or even
> 
>    Accept: application/vnd.openstack-nova-api+json; version=2.114
> 
> (and similar on the content-type header). There is precedent for
> this sort of thing in, for example, the github api.
> 
> (I'll not[1] write about "srsly, can we please stop giving Jackson the
> Absent so much freaking power".)
> 
> [1] whoops

Realistically, this was in one of the early proposals. But one of the
challenges with content negotiations is that if we actually did this as
content negotiation then you also need to support quality levels like

Accept: application/vnd.openstack-nova-api+json; q=0.8; version=2.114,
application/vnd.openstack-nova-api+json; q=0.5; version=2.110,
application/vnd.openstack-nova-api+json; q=0.2; version=2.100

The complexities in thinking through the programming for that on the
client side were a little odd. Enough so, that with other concepts we
were trying to get out there, this seemed like it was just going to
confuse everyone quite a bit. Better to err on the explicit side.

It also meant that the fall back case semantics were less clear. Because
existing clients would just be requesting application/json. Which isn't
application/vnd.openstack-nova-api+json at all.

The Jackson the absent case is kind of important, because we were told
by public cloud providers that turning off v2.0 is not an option for
them in any forseable future. Major upgrades are hard, especially when
you have a lot of people using an interface. See "python 3" for how to
do major version bumps in a way that no one moves onto your new stuff in
a timely manner. We're trying to explicitly avoid that by allowing
people to move forward on their own time table, and actually not have to
move everything at once.

	-Sean

-- 
Sean Dague
http://dague.net