Open Stack

No, not at all.

The object is /servers/1234 regardless of the versioning of the API. It's an object that exists independent of your API and its version. A URI should represent a single, persistent reference to that object.

The version is really an attribute of the content type you are accepting. It tells you what kind of content the client is expected to send to you and to receive from you. In particular, the structure of the data representing the persistent object.

/servers/1234 should always represent that 1 server. Forever. Unless the URI has changed, in which case a v1 client will respond with a 302 and a v2 client with a 404. A v1 client can then query /instances/1234 and get the version 1 xml or json. A v2 client querying /instances/1234 gets version 2 xml or json.

-George

On Oct 11, 2011, at 3:11 PM, Soren Hansen wrote:

> 2011/10/11 George Reese <george.reese at enstratus.com>:
>> Versioning should not be included in the URI. It belongs in the headers. A URI should be a persistent reference to a resource. As such, versioning always breaks that persistent reference.
> 
> I don't follow. If the version is included in the URI, that's got to
> be a more persistent reference to a resource than a URI whose
> behaviour differs depending on a header that you have to include?
> 
> -- 
> Soren Hansen        | http://linux2go.dk/
> Ubuntu Developer    | http://www.ubuntu.com/
> OpenStack Developer | http://www.openstack.org/

--
George Reese - Chief Technology Officer, enStratus
e: george.reese at enstratus.com    t: @GeorgeReese    p: +1.207.956.0217    f: +1.612.338.5041
enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com
To schedule a meeting with me: http://tungle.me/GeorgeReese

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4395 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20111011/d7aa7a36/attachment.bin>