Enhancement/issue 13 #74
Conversation
…espective payload.closes #1
…-post Changed the reconciliation service request method to post,added the r…
…-post Node engine version added to package json
…he manifest version
There was a problem hiding this comment.
Fantastic, many thanks for working on this!
As shown in @saumier's screenshot in reconciliation-api/specs#138 (comment), a validation error is currently shown for reconciliation responses, because they are validated against the JSON schema for 0.2.
I think this begs the question of how to better structure this code to make sure each component is behaving according to the expected version.
The approach you have taken, for instance in the Candidate component, seems to be to change the component so that it accepts whatever JSON format is returned by the service. To me, the purpose of the test bench is in a good part to validate the behaviour of the service, so I think there would be value in being stricter. For instance, if a 0.3 service returns a reconciliation response that matches the 0.2 version, we want to flag that, because a client that would only support the 0.3 protocol would choke on that.
The component could take as a prop the version of the protocol it should follow, and then accept only JSON content that would match that exact format (and ideally display a nice error if it does not). You could follow this approach everywhere, with the version to test against being selected only once, when reading the manifest. When it feels appropriate, you could even duplicate the component to make it version-specific, as it could keep the code within a component simpler.
Also, I noticed that the support for multilingual names and descriptions (reconciliation-api/specs#138) has not been implemented in the specs yet, so I think we should do that first.
| "0.1":"0.1", | ||
| "0.2":"0.2", | ||
| "0.3":"0.3", | ||
| "draft":"draft", |
There was a problem hiding this comment.
What is the motivation behind this object? If the keys are equal to the values, maybe it could be simply a list?
There was a problem hiding this comment.
@wetneb Yes, you are correct. If the keys are the same as the values, we can store it as a list. The primary motivation was to keep the versions in an object for easy reference throughout the code, ensuring we only need to update the value in one place if it changes.
culturecreates/artsdata-reconciliation#13