Stream: implementers
Topic: Vonk - API Function Validations
Medi Harsini (Feb 17 2020 at 13:32):
Has anyone got an experience around creating multiple workstream resources/profiles in Vonk which are related? if yes, do you know how to configure a resource creation (Post) if it is dependant on some other resources? For example, if you have got an encounter coming for an appointment but that appointment should have existed as a prereq, how do you check such the existence of appointment and then to allow the encounter publication? Broadly speaking validation a REST transaction based on some rulesVonk Interrelated Queries
Medi Harsini (Feb 17 2020 at 16:43):
@Lloyd McKenzie Can you please advise how this is done commonly speaking in FHIR
nicola (RIO/SS) (Feb 17 2020 at 17:16):
In aidbox, we check all references on create/update to ensure referential consistency.
Lloyd McKenzie (Feb 17 2020 at 19:03):
The standard mechanism would be to use the REST conditional create functionality (http://build.fhir.org/http.html#ccreate). I don't know if Vonk supports this though
René Spronk (Feb 18 2020 at 07:42):
Vonk does support it (conditional operations).
Verifying referential integrity has its benefits, but also its drawbacks, so it should be configurable (IMHO) on a server, not mandatory. On HAPI it's terribly hard to do 'garbage collection' when one doesn't require a particular graph of resources any more. Aid box doesn't have a public endpoint, so I don't know whether that suffers the same issue.
Medi Harsini (Feb 18 2020 at 12:06):
Thanks @René Spronk @Lloyd McKenzie @nicola (RIO/SS)
nicola (RIO/SS) (Feb 18 2020 at 13:54):
@René Spronk you can have your own aidbox for free in our demo cloud - https://aidbox.app
nicola (RIO/SS) (Feb 18 2020 at 13:57):
Aidbox treats relative url in reference as local ref and validates consistency; and skip absolute
Vassil Peytchev (Feb 18 2020 at 14:01):
It skips absolute, even if it resolves to a local reference? In other words, is the distinction made based on format only, or based on local vs. non-local regardless of format?
nicola (RIO/SS) (Feb 18 2020 at 14:16):
for performance reason, we do not try to resolve absolute urls (just relative)
nicola (RIO/SS) (Feb 18 2020 at 14:17):
We distinguish based on url format
nicola (RIO/SS) (Feb 18 2020 at 14:18):
I would like to have this difference explicitly in FHIR Reference :)
Paul Church (Feb 19 2020 at 16:19):
What's the difference you want to make explicit?
The Google implementation recognizes absolute refs that point to the same store the reference is in, and validates them as local refs. But that's just a matter of checking the URL prefix.
nicola (RIO/SS) (Feb 20 2020 at 04:53):
@Paul Church what if user wants to make absolute reference to resource, which is on different server? How do you distinguish for validation is it local or external
nicola (RIO/SS) (Feb 20 2020 at 04:55):
Ah you are talking about url prefix - that's reasonable if you have stable absolute url
nicola (RIO/SS) (Feb 20 2020 at 04:56):
we have servers with multiple domains and non REST integrations, but yeah it can be list of prefixes
nicola (RIO/SS) (Feb 20 2020 at 04:57):
will support same logic in next release ;)
nicola (RIO/SS) (Feb 20 2020 at 05:02):
@Paul Church one question - do you store local refs internally as resourceType/id pair?
Paul Church (Feb 20 2020 at 14:09):
Yes - we keep the original however it was specified (absolute or relative) and split it for internal use so it's consistent.
re: url prefixes - it's not perfect for us either, you could get to the same data through different endpoints. The motivation was just the case where the client is sending a resource to endpoint A, containing absolute urls matching endpoint A, and ref integrity is enabled.
Brian Postlethwaite (Feb 21 2020 at 11:30):
I'd need to recheck, but I'm pretty sure ours detects local ref's based on known set of prefixes, and then forces it back to local. So as not to cause issues when coming from other endpoints.
Last updated: Apr 12 2022 at 19:14 UTC
