search

openactive / open-booking-api

Repository for the Open Booking API specification
Other
2 stars 3 forks source link

Assumptions about availability of endpoints #89

Open nickevansuk opened 6 years ago

nickevansuk commented 6 years ago

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.

ldodds commented 5 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.

nickevansuk commented 5 years ago

Keep in spec

nickevansuk commented 4 years ago

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.