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?