Stream: implementers
Topic: Resource.id requirements
Alexander Henket (Aug 22 2019 at 16:39):
Resource.id says as comment "The only time that a resource does not have an id is when it is being submitted to the server using a create operation."
Also the resource.id is expected to serve as endpoint [base]/[type]/[id]
In our usual setup the FHIR is but a facade for something else which seldom to never allows for using any resource.id as endpoint. Behind most of our FHIR servers will be V3 messaging based systems for example.
Hence, again in our usual setup, we do not generate any resource.id and always contain or bundle any referenced data. This avoids the idea that any such resource would be accessible based on that id.
This seems to contradict the intention of the Resource.id comment in the spec. How do you handle being a FHIR server that only allows query based access if not like we do? Or is our method allowable and is the comment to be interpreted less strict?
Michele Mottini (Aug 22 2019 at 16:49):
I'd expect that returning resources without ids would break many clients - even if they do not use them to do direct GETs they would try to map or store them etc.
Lloyd McKenzie (Aug 22 2019 at 17:14):
Allowing "search" but not "read" would be quite odd. It's not strictly prohibited though. However, you would certainly expect to always be able to search by id if search is supported. If you don't have ids, you can't really expose a RESTful interface at all. If you want to use FHIR as a facade, figuring out how to produce consistent ids is your base point of entry.
Grahame Grieve (Aug 22 2019 at 19:42):
I don't understand this bit:
Grahame Grieve (Aug 22 2019 at 19:42):
we do not generate any resource.id and always contain or bundle any referenced data
Those require a id
Alexander Henket (Aug 23 2019 at 06:29):
In Bundle we rely on the fullUrl which is an ad hoc uuid/oid. No need for resource.id. To date we have not had to contain anything. Indeed an id of some sort would be required, but it would be ad hoc too.
Grahame Grieve (Aug 23 2019 at 06:35):
well, ok. I read the rules again and that works. Well, you could make a task to clarify the blunt statement that is only true on the restful interface
Alexander Henket (Aug 23 2019 at 06:39):
If you don't have ids, you can't really expose a RESTful interface at all. If you want to use FHIR as a facade, figuring out how to produce consistent ids is your base point of entry.
That is a clear statement. As it stands I'm a specifier, not an implementer, except for corner cases where we provide mappings. Resource.id as requirement could really be a killer for V3 facades that map as they are queried, without having any persistent storage itself. V3 has identifiers, not ids. Query by identifier is supported. Query by id has no meaning in that world, unless I simply copy the identifier onto the id, which may or may not be possible because of the length and character constraints of Resource.id.
Alexander Henket (Aug 23 2019 at 06:43):
Well, you could make a task to clarify the blunt statement that is only true on the restful interface
That might be a way forward. The situation is that all systems use the API spec in http.html which bears RESTful API in its title. Not every system can support Resource.id though, which limits the RESTfulness, I agree. But could they be compliant nonetheless?
Grahame Grieve (Aug 23 2019 at 06:50):
not using the RESTful interface - that depends on Resource.id. But when you get to messaging etc, then, sure.... there's other ways to organise things
Alexander Henket (Aug 23 2019 at 07:25):
not using the RESTful interface
We use everything in the http.html spec for search and create. We allow read, we do not require it. In practice we see that systems cannot handle ids for any or for some objects. Hence searching for ?_id=... will probably not yield anything
Alexander Henket (Aug 23 2019 at 07:26):
Added GF#23741
John Moehrke (Aug 23 2019 at 14:41):
This likely shows up in many FHIR API onto other systems. I suspect for example that IHE-MHD implementations with XDS or XCA backends do this very thing. I was careful in MHD to not forbid this kind of facade. Mostly because the Consuming application is 99% of the time going to just use Query and never use Read. To force support for Read of an Id just for religion (REST) is not helpful if it doesn't solve a problem. This is not to say that REST is bad, just that there are some API uses that have more compelling story around Create and Query only.
Last updated: Apr 12 2022 at 19:14 UTC
