[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Issue Comment Edited: (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=32645#action_32645 ]
Adrian Otto edited comment on CAMP-40 at 3/5/13 9:22 PM:
---------------------------------------------------------
In accordance with Roshan's comments, it would be possible to explicitly list which versions are backward compatible. For example, if the versions resource contained an array that listed each of the supported versions, each one could provide a list of versions it's backward compatible with.
Example:
{
"uri": "http://example.org/CAMP/versions";,
"name": "My list of CAMP Versions",
"type": "versions",
"created":" 2013-01-01T00:00Z",
"versionLinks":[
{
"targetName": "CAMP 1.1 Service",
"specificationVersion": "CAMP 1.1",
"implementaitonVersion": "RAXv1.1.0",
"backwardCompatibleImplementationVersions": ["RAXv1.0.0"],
"href": "http://example.org/CAMP/1.1/v1.1.0/Platform";
},
{
"targetName": "CAMP 1.2 Service",
"specificationVersion": "CAMP 1.2",
"implementaitonVersion": "RAXv1.2.3",
"backwardCompatibleSpecificationVersions": ["CAMP 1.1"],
"backwardCompatibleImplementationVersions": ["RAXv1.2.0", "RAXv1.2.1", "RAXv1.2.2"],
"href": "http://example.org/CAMP/1.2/v1.2.3Platform";
},
{
"targetName": "CAMP 2.0 Service",
"specificationVersion": "CAMP 2.0",
"implementaitonVersion": "RAXv2.2.0",
"backwardCompatibleSpecificationVersions": ["CAMP 1.1", "CAMP1.2",],
"backwardCompatibleImplementationVersions": ["RAXv2.1.0", "RAXv2.1.3"],
"href": "http://example.org/CAMP/2.0/v2.2.0/Platform";
},
]
}
Using this approach, it becomes much more clear which specificationVersions are backward compatible, and which implementationVersions are backward compatible with each of the available Platforms.
Each platform should identify itself as only one version. The backwardCompatible* attributes in the versions resource can be the indicator of which ones are compatible with the current one.
This approach also allows for a version to be revoked from the backward compatibility list if it's found to be unsupportable. This can happen in cases where a security vulnerability is discovered that requires an API contract change to resolve.
was (Author: adrian.otto):
In accordance with Roshan's comments, it would be possible to explicitly list which versions are backward compatible. For example, if the versions resource contained an array that listed each of the supported versions, each one could provide a list of versions it's backward compatible with.
Example:
{
"uri": "http://example.org/CAMP/versions";,
"name": "My list of CAMP Versions",
"type": "versions",
"created":" 2013-01-01T00:00Z",
"versionLinks":[
{
"targetName": "CAMP 1.1 Service",
"specificationVersion": "CAMP 1.1",
"implementaitonVersion": "RAXv1.1.0",
"backwardCompatibleImplementationVersions": ["RAXv1.0.0"],
"href": "http://example.org/CAMP/Platform";
},
{
"targetName": "CAMP 1.2 Service",
"specificationVersion": "CAMP 1.2",
"implementaitonVersion": "RAXv1.2.3",
"backwardCompatibleSpecificationVersions": ["CAMP 1.1"],
"backwardCompatibleImplementationVersions": ["RAXv1.2.0", "RAXv1.2.1", "RAXv1.2.2"],
"href": "http://example.org/CAMP/Platform";
},
{
"targetName": "CAMP 2.0 Service",
"specificationVersion": "CAMP 2.0",
"implementaitonVersion": "RAXv2.2.0",
"backwardCompatibleSpecificationVersions": ["CAMP 1.1", "CAMP1.2",],
"backwardCompatibleImplementationVersions": ["RAXv2.1.0", "RAXv2.1.3"],
"href": "http://example.org/CAMP/Platform";
},
]
}
Using this approach, it becomes much more clear which specificationVersions are backward compatible, and which implementationVersions are backward compatible with each of the available Platforms.
Each platform should identify itself as only one version. The backwardCompatible* attributes in the versions resource can be the indicator of which ones are compatible with the current one.
This approach also allows for a version to be revoked from the backward compatibility list if it's found to be unsupportable. This can happen in cases where a security vulnerability is discovered that requires an API contract change to resolve.
> 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]