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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev