API design considerations #15
Conversation
tlohmar
requested review from
PeterKovacs2,
alejandropalmier and
eric-murray
as code owners
|
I'm a little confused by the transition from Activated to Reserved based on Reservation end time described in line 23. Does this imply that a user of the API can request a Dedicated Network for a series of separate times in a single request? (e.g. every Wednesday from 9-10am) Or is there some other use case that requires a reservation that can move back to "reserved" after activated. |
|
@SteveV-Vodafone: Good catch. Indeed, one motivation would be to address use cases with recurring reservations. Not yet sure, whether handling of reoccurrence becomes too complicated. |
There was a problem hiding this comment.
Further detail on recurring reservations will be needed later (e.g. the transition from Active back to Reserved). Recommend we exclude this option from first release (as it can be managed externally by using multiple reservations).
Having a single reservation for multiple time slots may make it hard to report on performance if a single ID is used to identify the reservation. E.g. if a developer queries "was my SLA met for reservation XYZ" how can we answer if the reservation is not complete as it recurs every Wednesday?
tlohmar
dismissed
eric-murray’s stale review
The merge-base changed after approval.
tlohmar
force-pushed
the
api-design-considerations
branch
from
6eed805 to
69b8e95
Compare
|
resolving conflict. |
What type of PR is this?
Add one of the following kinds:
What this PR does / why we need it:
The PR provides a first draft of a API Design considerations document. Having a document allows to drive enhancements via Pull Requests and have a consistent view with collection of latest views.
Which issue(s) this PR fixes:
Fixes #10
Special notes for reviewers:
Changelog input
Additional documentation
This section can be blank.