Stream: implementers
Topic: Correct way to implement API
Thomas Johansen (Feb 06 2018 at 10:14):
Hi, see specc at bottom for reference.
We just started implementing FHIR and something bugging is me. We want to serve a bundle at [ base ]/CriticalInformation/ID. To achieve it we extended Bundle and serve this. I put up the web tester and it told me that I cannot serve this object. So I thought, is this wrong? In the specc you'll find many "custom" resources, but they are basically extending FHIR defined objects I.G AllergyIntolerance. We are using the Spring Boot implementation with hapifhir. That's why I extended a CriticalInformation object to achieve the endpoint. Is our strategy wrong or are there alternatives to doing this? Any pointers would be appreciated.
Thanks,
// Thomas
Our specc: https://simplifier.net/KritiskInfo/CriticalInformation/~overview
Grahame Grieve (Feb 06 2018 at 10:35):
I don't believe that you'll find any custom resources in the spec
Grahame Grieve (Feb 06 2018 at 10:36):
you can put up whatever end points you want, such as /CriticalInformation, but they're not conformant to the standard, which is why the web tester said what it said.
Thomas Johansen (Feb 06 2018 at 10:44):
Right, that's what put me off. But is the method of extending the classes correct, or am I supposed to do it otherwise? Reference to the endpoint is due to the @Read annotation that parses my getRerouceType of CriticalInformation.class to a REST endpoint of "/CriticalInformation/@IdParam". And about the conformant issue, can I move around this? Seems a waste to lose web tester possibilities when I only extend Bundle and serve it up. That's why I'm thinking this is wrong. I'm using this: https://github.com/jamesagnew/hapi-fhir/blob/master/hapi-fhir-spring-boot/hapi-fhir-spring-boot-samples/hapi-fhir-spring-boot-sample-server-jersey/src/main/java/sample/fhir/server/jersey/provider/PatientResourceProvider.java
Lloyd McKenzie (Feb 06 2018 at 18:51):
FHIR resources are "complete". You can't add any data elements to them by extending the reference implementation classes. (At least not while remaining conformant). To convey extra data elements with FHIR, you need to use the "extension" elements already present within the resources. These extension elements can be profiled to allow conveying pretty much any additional data you wish - while remaining conformant with the base FHIR schemas and remaining interoperable with other FHIR systems. Look at the section on "profiling" for more guidance.
Lloyd McKenzie (Feb 06 2018 at 18:51):
We have on our wishlist the ability to generate code for profiles that allows you to treat extensions and other sliced elements as if they were a core part of the resource, but we're not there yet.
john arastoozad (Feb 06 2018 at 21:31):
My current requirement for using FhirClient <Search> needs to be modified so that, for privacy reasons, no query parameters are passed in.
This leaves me with two options:
1- Use POST and pass searchParams using content-type of application/www-x-form-urlencoded .
2- Use Custom HttpHeaders
I opted for the second option, because it required least amount of code change: as the content of query string will be passed in thru a HttpHeader, instead of query string and NO changes will be required for Deserialization
Im seeking your feedback.
Thanks
Grahame Grieve (Feb 06 2018 at 21:35):
we always challenge your assertion: any user that has access to the URL has access to the entire request. So in principle, you don't achieve anything. There are some cases where you can be sure that the URL is shared and the rest of the request is not, so that moving search parameters out of the request achieves something, but it's always fragile.
Grahame Grieve (Feb 06 2018 at 21:36):
having said this, option #1 is conformant with the specification, and supported by most servers. option #2 is neither conformant with the specifiation, nor supported by servers. Further, it's not conformant with http itself (I think), and probably not supported by many implementation frameworks
John Moehrke (Feb 06 2018 at 22:06):
Security WG agrees with Grahame's statement, although we would acknowledge there is risk to mitigate. However the risk exists with GET URL parameters just as much as with POST search parameter content. There is misunderstanding that persists to this day that URL parameters are bad. There is indeed a risk that a URL might be stored or propagated by a human, but so too any other way that human gets data. URL GET parameters are only bad when exposed, but as Grahame points out those that have the authority to get a proper URL with parameters would be the HUMAN to expose that URL. That HUMAN is just as likely to expose the parameters (or resulting data). Applications, vs browsers, can prevent the HUMAN from this
Grahame Grieve (Feb 06 2018 at 22:09):
see, for example, how to configure IIS to log headers as well as requested URLS: https://docs.microsoft.com/en-us/iis/extensions/advanced-logging-module/advanced-logging-for-iis-custom-logging. This is a server side management problem, not a protocol issue
Lloyd McKenzie (Feb 06 2018 at 23:01):
@john arastoozad Thanks for at least asking the question in this forum. Checking these sort of design decisions is exactly what chat.fhir.org is for.
John Moehrke (Feb 07 2018 at 14:22):
Grahame, The server side is just management. Most client would also be services or applications, where it is also just management. The problem is when an API is used by a browser hosted application, there is little one can do to control a browser history/cache. For this I point out that one is already trusting that browser with the results of the GET request, so why is it not trusted with history? Others worry about proxy servers, but with proper TLS and trust-store management, there is no exposure; and GET is just as exposed as POST in those cases.
John Moehrke (Feb 07 2018 at 14:23):
I would like to get this captured on the Security & Privacy Module page as a FAQ... given that it is indeed a FAQ. Could someone propose a title, Use-case wording, and Approach wording?
John Moehrke (Feb 07 2018 at 14:28):
This line of risk is all about looking at past history of GET parameters to devine facts... GET parameters do not expose anything. They are just parameters, they don't indicate any facts. Anyone worried about GET parameters doesn't understand that I can 'edit' any text string I want, it doesn't indicate that text string is fact. It is more likely that GET parameters found in a history log did get results, but that GET might have returned no results found.
Simone Heckmann (Feb 13 2018 at 18:45):
I think what you are trying to achive is to define a message-type Bundle that has a specific predefined content. You may want to look at the FHIR messaging specification and the MessageDefinition resource...
Simone Heckmann (Feb 13 2018 at 18:48):
Some starting points:
http://build.fhir.org/messaging.html
http://build.fhir.org/messageheader.html
http://build.fhir.org/messagedefinition.html
Last updated: Apr 12 2022 at 19:14 UTC
