Stream: implementers
Topic: Operation Definitions for BASIC API
nicola (RIO/SS) (Nov 06 2016 at 07:32):
Why we do not have OperationDefinitions for basic FHIR API like CRUD, Search, History etc?
James Agnew (Nov 06 2016 at 12:53):
The basic REST API methods are covered in the CapabilityStatement (aka Conformance) under CapabilityStatement.rest.resource.interaction. There's a spot for a textual description there but it's really mostly just a binary "yes/no do i support this thing?"
nicola (RIO/SS) (Nov 06 2016 at 20:06):
:( i.e. hardcoded
James Agnew (Nov 06 2016 at 20:09):
What information are you trying to convey? I wouldn't say that I've found the options in capabilitystatement to be limiting so far..
nicola (RIO/SS) (Nov 06 2016 at 20:11):
What the difference between Operations as OperationDefinition resource and basic FHIR API?
James Agnew (Nov 06 2016 at 20:13):
I guess mainly the fact that the built-in operations (create/read/etc) all have their semantics completely spelled out by the FHIR spec, where operations are intended to have their semantics spelled out via an OperationDefinition resource. I don't understand why you'd want an operationdefinition for the built-in ones? What information are you trying to convey?
nicola (RIO/SS) (Nov 06 2016 at 20:15):
I'm trying to generate swagger spec for FHIR. Just uniformity principle - all REST API described as .... Isn't Operations are capabilities or capabilities are operations (Occam's razor)
James Agnew (Nov 06 2016 at 20:19):
Well, I could see how it would be useful for that one use case.
Seems like an annoying burden for server developers to have to meet though just to avoid having to look in two places in the capability statement when generating your swagger.
nicola (RIO/SS) (Nov 06 2016 at 20:24):
Yes :) complexity started by small inconsistencies and then hacking on top of it recursively. Semantically, are not Operations defined in OperationDefinitions at the same time server capabilities?
nicola (RIO/SS) (Nov 06 2016 at 20:25):
Why do we need two concepts for one entity?
James Agnew (Nov 06 2016 at 20:31):
I guess because you have to draw the line somewhere when deciding how much complexity to add.. I mean, even if you did generate OperationDefinitions for the FHIR built-in operations, you wouldn't be able to convey all of the information you would need to in the existing resource.
E.g. what would an OD look like for the update operation? There is nowhere in there for you to specify what HTTP verb it requires.. Nor is there a way to convey the conditional URL that is allowed, or the extra headers. In the end if you wanted to be able to just automatically generate swagger from an OD, you would need to extend OD quite a bit and in the end you're just re-creating swagger in another form.
Ultimately that's way more complex than just saying "yes/no i support update"
nicola (RIO/SS) (Nov 06 2016 at 20:37):
This problems brings us to the right direction - that OperationDefinition should be extended to include such type of information. Swagger generation is only one use case. Now we use code generation for FHIR resources, the same way OperationDefinitions could be used to generate API Calls, Generic UIS. Swagger has good support for client generation and generic Swagger UI.
Last updated: Apr 12 2022 at 19:14 UTC
