[OASIS Issue Tracker] Commented: (CAMP-40) version array resource/thing has a number of problems

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/CAMP-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32686#action_32686 ] 

Adrian Otto commented on CAMP-40:
---------------------------------

I really like Gil's proposal, and the direction we are now headed with this.

I extended Gil's proposal to conform more closely with the pattern defined in CAMP-39. It includes concepts of Endpoints, Endpoint, and includes a diagram that describes the justification for having the backward compatible attributes outside of the platform resource to allow full version discovery prior to authentication, if desired.

Please consider this as a possible alternative proposal:

https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48511/camp-spec-v1.1-wd07-issue40-v5.doc

Feedback requested.

> 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
>            Priority: Critical
>
> 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