reconciliation-api / specs

Specifications of the reconciliation API
https://reconciliation-api.github.io/specs/draft/
31 stars 9 forks source link

Describe compatibility requirements for clients and services #111

Closed tfmorris closed 1 year ago

tfmorris commented 1 year ago

Perhaps I've missed it, but I don't see anything which describes how compatibility works, e.g. protocol version negotiation, forward/backward compatibility, etc.

I think it would be useful to describe what the requirements/expectations are from both the services' point of view and the clients point of view -- and, perhaps, what the general rules are for updating the spec with regard to compatibility.

As an example of a thing I don't understand - the versions array in the service manifest can include multiple protocol versions. If a service advertises [0.1, 0.2, 0.3] how do they know what protocol version the client is using? This is important since, for example, the existing OpenRefine protocol and 0.1 mandate a single type, while 0.2 allows either a single type or an array of types and 0.3 mandates an array. The receiver (service) needs to know what to expect to be able to parse it properly.

It's probably a simple set of rules, but they should be documented for both ends.

wetneb commented 1 year ago

Is this a duplicate of #78?

0.1 mandate a single type, while 0.2 allows either a single type or an array of types and 0.3 mandates an array

As a side comment, I don't see any change between 0.1 and 0.2 on this matter.

tfmorris commented 1 year ago

I think it's a superset, but let's broaden the discussion there rather than having two separate discussions.