Open nickevansuk opened 6 years ago
On our last discussion, there was a request to retain the ability to do an availability check, as currently specified.
As we don't have an opportunity API specification, for Version 1.0 of booking I suggest we keep it in this specification. We can separately decide whether to move it into the opportunity API in a future version.
Keep in spec
C1 and C2 remove the need for an availability check.
However a sentence should be added to the spec to clarify the use of @id
, something like:
@id
properties are used as identifiers throughout this specification, due to the use of JSON-LD. The value of such a property MUST always be an absolute URI that provides a stable globally unique identifier for the resource, as described in RFC3986. The primary purpose of the URI format in this context is to provide natural namespacing for the identifier. Hence, the URI itself MAY not resolve to a valid endpoint, but MUST use a domain name controlled by the resource owner.
The broker should not assume, either when reading an open data feed or when using the Open Booking API, that any object's ID will resolve to a URL which the broker has access to.
For example
https://example.com/places/452
might be restricted as part of the Opportunity API, and access MUST NOT be required by any part of the Open Booking API.This statement should be included in the spec to make the modularity clear.