Currently the API Management data model includes a version number for both applications and services. The idea is that once a particular version of a Service is published it cannot be updated. Instead, a new version of the Service must be created, modified, and then published. The reason is that any Applications that are invoking the Service need to have some guarantee that the terms of the Service Contract will not change out from underneath them.
Note: a nice side-effect of this data model is that multiple versions of an *implementation* of a Service is also easily supported.
However, this does mean that every time a Service is modified and re-published, it will have a new version associated with it. Which also means that Application implementations may need to be updated with this information. Why is this? Because the Service's version number is currently encoded in the gateway endpoint.
Specifically, the current endpoint format for the Gateway is as follows:
As a result, the [version] portion of the endpoint URL will change every time a Service's details are changed.
It is important to understand that the actual service *implementation* could be changed out from underneath the API Management system, since those back-end service implementations are likely independent. In other words, if the back end service is a REST service, the developer could change the logic of the service and re-deploy it to the same REST endpoint without the API Management layer ever noticing. I believe this is outside the scope of the API Management layer.
It is also necessary to understand that Applications will be invoking the Service via a Contract. Therefore, if a Service changes frequently, it might necessitate an Application to create new Contracts to the new Service versions. It would also mean that the actual Application implementation would need to be updated to include the updated Gateway endpoint information for the Service.
objectiser suggested that this might be too granular an approach and place too much of a burden on Application developers - requiring them to create new versions of their apps very frequently.
The first question is this:
Is it likely that Service configurations will often change? This includes new versions of the Service's back end implementation, as well as API Management configuration changes to the Service such as modified Policies.
If we answer YES to the above question, then I can think of various strategies to mitigate the Application developer's burden. I will describe one possible solution (assuming a Yes answer above) as a reply (see below).