-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decide on linking #19
Comments
I did a quick investigation of REST hyperlinking schemes. For self-links the many variants of HATEOAS really come down to two: The third option is to use neither, but "roll our own" - for instance "self-url" : "https://...". Simpler but way less standard. |
I'm going to add comments from email conversations to this thread to capture them here for reference by other contributors. |
Was indeed good to meet everyone in ‘real life’ :) Wrt your 2nd and 3rd points; I’ll leave that to the experts. Wrt to the hyperlinking: just a few thoughts here:
What are your thoughts on compulsary vs recommended in this area? So, no strong opinion on my side other than a slight preference for either JSON-LD or Hyperschema. |
Thanks for the feedback Arjan, Regarding the hyperlinking: compulsory vs optional. I also prefer either JSON-LD or JSON Hyperschema over HAL. We had gone with JSON-LD in DataLinker because: a. The involvement of Google, Microsoft, and others in JSON-LD gave us some confidence in the level of community support; However, we can make our own decision here on what to use. It may be that we can define schemas in such as way that there is no great difference between JSON-Hyperschema and JSON-LD. For instance let’s imagine that an animal had a “sire” property which contained the ID of the sire and a link to the sire’s animal resource. JSON-LD: JSON-Hypermedia |
I wasn’t at ICAR, so I may be a little out of the loop. My thoughts on the points below. 1: I have no real preference on which standard is used, as long as a standard is used. I wouldn’t have worked with Hypermedia or LD in the past so I wouldn’t be making an informed decision. 2: “Arrival/Departure: Origin, Destination, transporter/Haulier, transport reference number, vehicle registration, date/time loaded, date/time unloaded, farm assurance reference” “Death: Reason, disposal method, disposal reference/receipt number” Sometimes reason for death has come up as an interest to certain parties, but not everyone. I wonder how often it is known and to what accuracy? 3: The array of parents would scale well, and there would be a preference for 3 generations for pedigree animals. |
Really good thoughts and questions, thank you.
|
At the meeting on 28 June 2019 it was felt that either JSON Hyper Schema or JSON-LD were reasonable, and I undertook to investigate further JSON Hyper Schema. An issue with JSON Hyper Schema is that it is designed principally to be declarative at the time of schema/API definition, and doesn't completely lend itself to cases where the implementation and format of URLs is not known or there may be a number of implementations. This is because links are defined as URI Templates in terms of RFC 6570.
This is great, but it does lend itself to URIs being specified in only one way, using one protocol, which is not what we are trying to achieve. It is hard to override this for specific implementations, as the URI Template is specified in the schema. For instance: As many of you know, I prefer the former approach (not specifying the exact URL paths in the schema which applies to every implementation). |
In terms of link relations (the "rel" part of a link), the following from the IANA registry are likely to be useful to us: Then inside collections: We may need to define our own link relations to describe links to:
|
I have defined:
|
The collection changes referenced above have been addressed by #73. We implemented Link Description Objects ("links" array) in icarResourceReference and icarResourceCollection, but because we have multiple files included with $ref, and hence can't include the "schema" keyword, these are not recognised and fail validation. We have removed the "links" array as the links themselves are still clearly documented in the schema without this. See commit #74. |
There is a need for automated discovery of urls. Parties that connect to multiple servers should not rely on client side synthesizing urls. Instead, the server should provide links in the messages to related resources.
The workgroup should choose such a standard (e.g. JSON-ld or hateoas or something else).
As long as we don’t have committed to this, we need temporary workarounds like example url schemes to document the standard.
The text was updated successfully, but these errors were encountered: