We had a discussion about having multiple versions of service/building blocks along with the notion of an API that combines multiple services or building blocks under the same resource tree.
Some of the considerations discussed:
Having multiple versions of the same API/block in the same tree. Requires them to be compatible, will make the API document grow.
Hosting incompatible versions at different resources/URLs. Then one has to figure out what other APIs to pick to complete that new tree offering (assuming service/blocks won't be evolving so that we have a "version " of them released at the same time).
Having links to different sub-resources offering different versions of a given block/service (e.g. two or more "collections" links). However, right now there is no way to specify the version number of a service/block/conformance class supported by a given link.
I'll also note that this is probably not going to be a big problem for an ad-hoc, single-purpose service, which can just choose whatever is best for their needs at the time of implementation.
It's more of an issue for generic server interested in offering multiple versions of the same service/block, to allow old and new clients to connect to it (SDI vision, more than single-purpose stack often consumed by a single web front end).
We had a discussion about having multiple versions of service/building blocks along with the notion of an API that combines multiple services or building blocks under the same resource tree. Some of the considerations discussed:
I'll also note that this is probably not going to be a big problem for an ad-hoc, single-purpose service, which can just choose whatever is best for their needs at the time of implementation. It's more of an issue for generic server interested in offering multiple versions of the same service/block, to allow old and new clients to connect to it (SDI vision, more than single-purpose stack often consumed by a single web front end).