OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

amqp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: AW: [amqp] Groups - amqp-man-v1.0-wd15.docx uploaded

URI path segments for versioning easily turn into an awful mess.


I’m okay with adding an “api-version” query parameter and “api-version” HTTP header to indicate the version of the API once we need it. For v1.0, which is the API version we define here, there is no other version, though. There’s no harm in not having that header until we actually introduce v.Next


The type version is still required, because you might introduce upgrade of the Queue type while not changing the API per-se-


Von: Rudyy, Oleksandr <oleksandr.rudyy@jpmorgan.com>
Gesendet: Freitag, 12. Juli 2019 16:38
An: Clemens Vasters <clemensv@microsoft.com>; 'amqp@lists.oasis-open.org' <amqp@lists.oasis-open.org>; 'Rob Godfrey' <rgodfrey@redhat.com>
Betreff: RE: [amqp] Groups - amqp-man-v1.0-wd15.docx uploaded


Hi AMQP TC Committee,


I would like to clarify my suggestion to model versioning.


As per my previous email, currently amqp management spec does not provide a versioning of entire model. It only offers versioning of entity types through property “type version”. The latter does not allow to access the same entity using different versions of management model. Though, it allows to have entities of different versions.


I think, that amqp management should provide versioning of management model similar to versioning of REST API. The version of management model can automatically apply to all entity types within the model. Thus, if client only supports previous management model and that management model is still supported by the broker, it should be able to access all broker management entities using previous model version operations, collections, etc.


I think that root $management discovery document should only provide information about current and supported versions. Thus, request to $management should return json with current version and relative addresses of all supported versions. As result, the particular version management URLs would look like






By navigating to the version link, the version specific model discovery document should be returned to the user (containing collections, types, operations, configuration)


Apart from latest model version and supported version management addresses, the $management document can contain such information like


The versioning of entire model would make  redundant “type version” in meta-type.


Kind Regards,





From: Rudyy, Oleksandr
Sent: Friday, June 28, 2019 6:05 PM
To: 'Clemens Vasters' <clemensv@microsoft.com>; 'amqp@lists.oasis-open.org' <amqp@lists.oasis-open.org>; 'Rob Godfrey' <rgodfrey@redhat.com>
Subject: RE: [amqp] Groups - amqp-man-v1.0-wd15.docx uploaded



I would like to re-iterate the issue I raised during last TC meeting about versioning of entire model.


The current management draft only defines versioning of entities. There is no versioning defined for entire management model.

I think it would be useful to add it in some way.


That should allow to distinguish current management model from previous ones by client connecting to management nodes and expecting a support of certain management model version.


Additionally, it would be useful to add a mechanism of communicating of supported management models. Thus, if broker supports management model versions 1.0 and 2.0, and, client only supports management model version 1.0, it can switch to older management.


I hope that the above makes sense J


Kind Regards,


This message is confidential and subject to terms at: https://www.jpmorgan.com/emaildisclaimer including on confidential, privileged or legal entity information, viruses and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]