Availability check for facility use slot does not scale

[nickevansuk]

Feedback on availability check approach

Although the current approach to availability checking does make satisfying use of the Event "id" property, it has challenges in several scenarios:

Feedback on EXAMPLE 11: Facility use response

The current approach of retrieving all slots for a particular FacilityUse at the start of the booking- which by as many as 840 slots for 30 minutes slots and a month lookahead - is not practical.

Feedback on EXAMPLE 7: Event response

In cases where ScheduledSessions may be materialised months into the future, or where they are generated from a Schedule, the Event will contain an excess of the data required to check availability.

Feedback on EXAMPLE 9: Slot response

In some cases more than one slot will need to be checked for availability, for example in the case of booking two consecutive hour slots. This currently requires two requests. Additionally for the Slots to be be meaningful (they do not contain any descriptive context for the end user), a further call to retrieve the related FacilityUse is required. This is assuming there is value in getting the latest data related to the description of the event or slot before it is purchased and not just relying on the open feed (this was the assumption which led to the current availability check approach which returns the entire Event).

Suggested fix

Although 7.1.3 Checking availability and offers for an event or facility use slot provides a useful means of accessing data relating to sessions without relying on the open feed, it does not provide a satisfactory means to check availability in advance of a purchase.

7.1.3 Checking availability and offers for an event or facility use slot should be moved into the Opportunity API, where it fits nicely, and this section of the Open Booking API specification should be replaced with OrderQuotes (#87).

Moving the section into the Opportunity API (as per #90) also resolves some of the issues with scale identified in the feedback above, as it allows query parameters to be specified to retrieve a specific subset of Slots or subEvents - and these should be defined as part of the Opportunity API instead of as part of the Open Booking API.

Noted considerations for this fix

• There will no longer be a means of retrieving the latest availability for a number of subEvents outside of the Opportunity API and open feed, however arguably this facility fits better in the scope of the Opportunity API, and this separation provides clearer modularity between opportunity API and booking.

[nickevansuk]

The approach to use C1, C2 and B which was introduced since this issue was created completely solves this.