Open lukehesluke opened 2 years ago
Great point @lukehesluke, and this makes sense to me - and the implementation could get very confusing otherwise, on both sides
Yes this makes a lot of sense, although I think we should avoid calling it UUID
and use id
or identifier
instead, as not all implementations will be using UUIDs
Summary
In the Open Booking API, in all Orders RPDE feed examples, each RPDE item has the Order's UUID as its
id
.e.g.
Afaict, the Open Booking API doesn't mandate that this must be the case, but should it?
This issue proposes that we mandate that, for Orders RPDE feeds, the RPDE ID must be the Order's UUID (i.e. have the same value as the Order's
identifier
).This'll make it easier for Brokers to understand what's happened in the feed, and in some cases is necessary to prevent permanent loss of information (see Scenario)
Scenario
Consider this scenario:
ddff9de2-8658-4a2c-9ae7-b9f946705214
The Order will only appear in the feed at step # 2. If this Orders RPDE Feed uses an arbitrary ID as its RPDE ID, then there is no way that the Broker can read that item from the feed and discern which Order was deleted.
The RPDE item may look like:
As this has no UUID, the Broker cannot cross-reference it with their own Orders and so have no way of knowing that Order
ddff9de2-8658-4a2c-9ae7-b9f946705214
has been deleted.Additionally...
Additionally, the Test Suite as it is presently written will only work for Orders RPDE feeds which follow this rule