This is partially related to API versioning but that's another EPIC. Providing history view of changes done to API profile is valuable information when evaluating API. It's also good information for consumers.
Examples of content
The history would contain information about the changes. Here's a few examples:
Every time API name has changed.
Every time when description has changed
Every time lifecycle status has changed
Every time Documentation URL or file has changed. (we would actually need to store uploaded spec files and urls. This is related to version management mentioned in the beginning)
Every time when proxy settings have changed
Every time when version is changed (not included atm in out datamodel, but has to be added at some point)
Every time rate limiting has changed
The above are just examples, there's probably more of those. From each of those the consumer needs to see (when possible not always) what exactly changed from this to that. An example: if the rate limiting has been so far 10 000 API calls per week and it's changed to 100 000 API calls per week , then consumer should see a message:
"21.12.2017 05:02:02 Ratelimiting changed from 10 000 to 100 000 per week"
Access history from API detailed view
Long list of events in history should be accessible from detailed API view. Default timespan to cover would be a month. User should also be able to define longer timespans to view. Alternative for that is to provide link "load more..." in the bottom of the event list.
The latest changed should also be visible in initial view of the API (the initial tab where user lands).
User Story:
"As an API consumer, I want to see history of the API; what has been changed and when to evaluate API and track versioning of it"
ilarimikkonen
commented
5 years ago
Description:
This is partially related to API versioning but that's another EPIC. Providing history view of changes done to API profile is valuable information when evaluating API. It's also good information for consumers.
Examples of content
The history would contain information about the changes. Here's a few examples:
The above are just examples, there's probably more of those. From each of those the consumer needs to see (when possible not always) what exactly changed from this to that. An example: if the rate limiting has been so far 10 000 API calls per week and it's changed to 100 000 API calls per week , then consumer should see a message:
Access history from API detailed view
User Story:
"As an API consumer, I want to see history of the API; what has been changed and when to evaluate API and track versioning of it"
Related Epic
3120