[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (CAMP-40) version array resource/thing has a number of problems
[ http://tools.oasis-open.org/issues/browse/CAMP-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32478#action_32478 ]
Adrian Otto commented on CAMP-40:
---------------------------------
> I've been thinking about it, and I don't think defining "specificationVersion" as an array is necessary. Assuming we
> follow the best-practice rules for versioning (yet another issue here), all CAMP 1.x servers should be able to support
> clients that use CAMP 1.y - where y <= x. Assuming that it doesn't make sense to claim that a single instance of a
> Platform-tree can simultaneously support both CAMP 1.x and CAMP 2.x (since the major-version bump indicates
> non-backwards-compatible changes), "specificationVersion" should simply list the latest version of the CAMP
> specification supported by that Platform-tree.
My operational experience (launching several REST API cloud services over the past few hears) has taught us that backward incompatible changes are a fact of life when hosting APIs. No matter how well designed an API is, about a few months after launch you need to fix it. When that happens, you break clients *unless* you have a version discovery framework. I think this feature has considerable merit, and we should proceed with the design process.
> version array resource/thing has a number of problems
> -----------------------------------------------------
>
> Key: CAMP-40
> URL: http://tools.oasis-open.org/issues/browse/CAMP-40
> Project: OASIS Cloud Application Management for Platforms (CAMP) TC
> Issue Type: Bug
> Components: Spec
> Reporter: Gilbert Pilz
> Assignee: Gilbert Pilz
>
> There are a couple of problems with the version array resource/thing defined in section 6.8.
> 1.) Unlike all the other things you can use HTTP GET to retrieve, the array of available versions is not defined as a first-class resource (i.e. it has no "type", "uri", "name", etc.) In the interests of simplicity it would be better if clients didn't have to special case the code that retrieves the version array.
> 2.) Placing the version array resource "under" the platform resource (i.e. at <platform-url>/api/versions) creates an inherent aliasing problem. For example, suppose a provider concurrently supported by CAMP 1.1 and CAMP 1.2. They might have a "Versions" resource that looked like the following:
> [
> { "version" : "1.1", "href" : "http://camp.example.org/1.1";, "name" : "nCAMP 0.9 POC" },
> { "version" : "1.2", "href" : "http://camp.example.org/1.2";, "name" : "BaseCAMP 1.0" }
> ]
> Should a client expect to be able to retrieve this resource through either "http://camp.example.org/1.1/api/versions"; or "http://camp.example.org/1.2/api/versions"; ? Should a client expect the representation of the resource at "http://camp.example.org/1.1/api/versions"; to be the same (baring any unexpected updates) as the representation of the resource at "http://camp.example.org/1.2/api/versions";? If we did decide to represent the version array as a first-class resource, what should the value of its "uri" attribute be?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]