Safely combine updates from the Opportunity API and RPDE Feeds

[nickevansuk]

Proposer

ODI

Use Case

In order to safely combine updates from the Opportunity API and Open Data Feeds, a common sense of "modified" timestamp is required.

For example:

• A call to the Opportunity API of /events/123 shows "remainingAttendeeCapacity": 1:
• The last item for /events/123 received from open data feed is "remainingAttendeeCapacity": 0

How do we reconcile which is the most recent between these in order to update a broker's search index or item cache?

Proposal

Option 1

• All items returned from the Opportunity API include a "modified" property in the same format as RPDE (unix timestamp preferred - Enforce integer modified date and afterTimestamp as MUSTs. openactive/realtime-paged-data-exchange#89), and must include an "id" field to match the RPDE "id"
• The next version of RPDE will update the "id" property to "identifier" for consistency (Overloading of "id" across JSON-LD and RPDE openactive/realtime-paged-data-exchange#87).

Option 2

• The next version of RPDE "id" should be equal to the "id" URI used within the Event.
• The next version of RPDE "modified" will be made an ISO 8601 date, and the option to use an integer "modified" (including the afterChangeNumber) representation removed.
• Further fixes to make RPDE and Opportunity API more consistent (see Bring RPDE in line with JSON-LD and remove duplication openactive/realtime-paged-data-exchange#90)

Option 3

• All JSON-LD data returned from the Opportunity API and RPDE feeds includes a "modified" property (added to Thing), which can be used to compare any object in the object graph. This works separately and in parallel with the RPDE id/modified mechanism.

Option 4

• All responses returned from the Opportunity API include a "Last-Modified" header in the same format as RPDE (unix timestamp preferred, with sub-millisecond precision - Enforce integer modified date and afterTimestamp as MUSTs. openactive/realtime-paged-data-exchange#89), and must include an "id" field to match the RPDE "id"
• This option has issues as it assumes all items returned by a particular Opportunity API call have the same modified date.