search

openactive / open-booking-api

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

Order Deletion request is idempotent #237

Open nickevansuk opened 1 year ago

nickevansuk commented 1 year ago

Three lines in the spec appear to conflict:

  1. "All Booking System endpoints defined in this specification must be idempotent."

  2. "GoneError": "An Order has been soft-deleted by an Order Deletion request."

The Test Suite implements (1), which is consistent with the overall design of the specification.

The second line should therefore be updated for clarity:

  1. "GoneError": "An Order has been soft-deleted by an Order Deletion request (not applicable to Order Deletion requests, which are idempotent)."
nickevansuk commented 1 year ago

Additionally the following should be clarified within 9.2.7 Order Deletion:

When an Order is deleted the Booking System should ~hard~ delete it as though it had not been created in the first place ~(~, with only a stub deleted record remaining. ~, for the Orders feed, if necessary), but may soft delete it providing~ All related personal data must be purged. The audit for the deletion is guaranteed to be stored in the Broker in all cases.

The Booking System must return an OrderAlreadyExistsError in response to C1, C2, P or B if the request includes a soft deleted / redacted or stubbed Order UUID.

An Order Deletion request must simply return a 204 success status when an Order is successfully deleted. The endpoint is idempotent, so a 204 MUST be returned upon subsequent calls to the delete the same Order.

An Order Deletion request must return a 404 status when the specified Order is not recognised, and should return a NotFoundError response.