Hi Eric

Your conclusion sounds reasonable, but just want to understand the implications more.

So an App would be configured to use a particular version of a plan and service? In which case, if an amendment was made to a plan - e.g. to update the billing rates, then what is to prevent the App remaining on the previous version - and therefore paying less?

Wondering whether an App should have the ability to decide these things - possibly instead of versions it needs a concept of activation - so at a particular point in time, a new instance of the plan becomes active, and from that point onwards the App will automatically be using it?

My concern with the use of versions is that the App configuration would then need to be updated to explicitly reference the new version.

In terms of versions for service - I just want to be clear, this is not the versioning of the actual service, but of the configuration information associated with the service endpoint, and any service specific policies?

As you mention, service configurations could be retired when no longer supported - but would need to understand the impact on Apps still configured to use that service. If a suitable solution could be found for this, then the same approach could also be used for versioning plans - i.e. when Apps need to move to a new plan version (with higher billing rate), possibly the old plan is retired - any Apps still referencing the old version are then either automatically bumped up to the new version, or become inactive as there is no valid plan available?

Emails could automatically be sent out to App owners/administrators notifying them of pending changes such as this - and maybe they could have configuration options on the App to indicate whether version updates should be automatically accepted or require manual intervention.

We may need to go through some dry runs to see how the impact of version changes at each level could impact the different users.

Regards

Gary

Sounds good for now.

Some of the actions may need to be scheduled - e.g. deploying a new plan and service, and auto upgrading apps using an old plan to a new one - to enable things like price plan changes to "automatically" be updated.

As a slight aside, in the current scenario I am assuming the App owner/admin will select the plan they wish to use. This is ok for the model where usage is billed based on the details associated with the plan.

The other approach that may be required is where an App owner prepays for use of a particular Service under a particular Plan. In which case, the App owner would need to go through a separate stage where they do the financial transaction (out of scope for apiman at present), but then some other admin function establishes the link between the App/Plan/Service. In this situation, this relationship would need to be locked - possibly just readonly?

Do you think it could be useful to have the flexibility to allow more sophisticated users to define how they want these state changes to be implemented (essentially arbitrarily)? For example, by some kind of rules definition or perhaps a sufficiently flexible API.

- X releases v2 of their Maps API, and in response they close access for new applicants to v1, reduce the number of requests for existing users, and after a set date start returning 410.

- If payment is not received on the expected date then the user is downgraded to the basic package.

- If request limits are reached, push a message with user info into the ESB (for consumption by an alert system).

I'm not sure what the best approach for that would be. I just imagine it'd be very hard indeed to cover all of the possible user requirements with 'pre-baked' options.