Stream: implementers
Topic: CapabilityStatement operation addition
Sean McIlvenna (Jan 28 2018 at 17:55):
What do people think about adding a property to CapabilityStatement.rest.operation for representing whether the server fully supports the operation. In the case of the $expand operation, it is common for servers to support GET /ValueSet/[id]/$expand, but not very common for servers to support POST /ValueSet/$expand. There is no way that I can see to determine if a server fully supports $expand or not based on the CapabilityStatement.
Sean McIlvenna (Jan 28 2018 at 17:55):
Not sure what the additional property would look like... but, I think something more is needed.
Eric Haas (Jan 29 2018 at 08:20):
Should be an element or extension of opdef not the cs just like profiles
Grahame Grieve (Jan 29 2018 at 13:59):
yes it is a property of OperationDefinition
Rob Hausam (Jan 29 2018 at 14:16):
Can I use that to determine the behavior of a particular server?
Grahame Grieve (Jan 29 2018 at 14:17):
you're supposed to be able to - but it's up to the server
Grahame Grieve (Jan 29 2018 at 14:17):
in this case, does the server list valueSet as a possible parameter
Sean McIlvenna (Jan 29 2018 at 15:23):
a lot of the terminology servers I hit (I believe) didn't even implement OperationDefinition
Sean McIlvenna (Jan 29 2018 at 15:23):
they just reference the core ValueSet-expand operation definition from http://hl7.org/fhir
Grahame Grieve (Jan 29 2018 at 15:26):
i reference those because I implement those
Sean McIlvenna (Jan 29 2018 at 15:30):
yes, you do... but few others do
Eric Haas (Jan 29 2018 at 16:35):
Um... There is currently no parameter on OD to define this. I will create a tracker but wondering if propose it should be an extension or element.
Grahame Grieve (Jan 29 2018 at 17:07):
to define what?
Eric Haas (Jan 29 2018 at 17:16):
whether use GET or POST or BOTH ( if you only have simple inputs case)
Grahame Grieve (Jan 29 2018 at 17:26):
OperationDefinition.affectsState
Sean McIlvenna (Jan 29 2018 at 18:18):
I think either we need to make it clear to terminology servers that they should support OperationDefinition, and they need to define their own version of the $expand OperationDefinition that represents their implementation, OR we should consider making changes to CapabilityStatement to make it easier for people to express their supported implementations of OperationDefinition
Grahame Grieve (Jan 29 2018 at 18:19):
the intent is clearly the first. We moved this stuff into operationDefinition.
Sean McIlvenna (Jan 29 2018 at 18:19):
as it stands, I get the impression that terminology servers think it is enough to support /metadata (CapabilityStatement) and just reference core profiles... but, that doesn't seem to be the intent based on what you guys are saying
Grahame Grieve (Jan 29 2018 at 18:19):
you can make it clear by complaining that they are not living up to their contract
Grahame Grieve (Jan 29 2018 at 18:19):
it's very clearly not the intent
Sean McIlvenna (Jan 29 2018 at 18:20):
I'll bring it up with the terminology group
Eric Haas (Jan 29 2018 at 18:24):
.affectState does not answer the question. That tells whether is Idempotent and you can only use POST as a result. If you may use either a GET or a POST then you should be able to specify it too. agree?
Peter Jordan (Jan 29 2018 at 18:24):
Mea culpa. I'll endeavor to implement this before C18. I suspect that it's not only terminology server implementers who are guilty.
Grahame Grieve (Jan 29 2018 at 18:24):
we are using operations the most
Peter Jordan (Jan 29 2018 at 18:26):
...and (some of) our operations are the most mature.
Rob Hausam (Jan 29 2018 at 18:27):
So, assuming that this is specified in the referenced OperationDefinition resource for each rest.resource.operation element in the CapabilityStatement that is returned from the 'metadata' interaction, then I think this should work.
Sean McIlvenna (Jan 29 2018 at 18:30):
@Rob Hausam , the problem is that almost none of the terminology servers even support OperationDefinition resources. I tried GET /OperationDefinition on almost all terminology servers I played with, and got mixed error responses (most saying "not supported" in one way or another)
Grahame Grieve (Jan 29 2018 at 18:36):
they can publish their operation definitions on a web site and reference thenm
Eric Haas (Jan 29 2018 at 20:19):
... but besides saying its idempotent and hence you need to POST, there is no way to define whether you can use POST/GET/BOTH and I think that relates to Sean's original post.
Grahame Grieve (Jan 29 2018 at 20:21):
servers SHALL support post for all operations.
Eric Haas (Jan 29 2018 at 20:23):
OK what about GET?
Grahame Grieve (Jan 29 2018 at 20:25):
shall support GET for affectsState=false
Eric Haas (Jan 29 2018 at 20:25):
Thanks
Eric Haas (Jan 29 2018 at 20:38):
in the resource :
"Operations that have affects state = false (see HTTP specification definition of idempotent ) may be invoked by performing an HTTP GET operation instead of a POST." vs
in Operations page:
"If all the parameters for the operation are primitive types, and the operation has affectsState = false (see HTTP specification definition of idempotent ), the operation may be invoked by performing an HTTP GET operation where all of the values of the parameters are appended to the URL in the search portion of the URL (e.g. after the '?' character). Servers SHALL support this method of invocation. ..."
What if some of the parameters are primitive and you only send those. MAY/SHALL the server support the GET method?
And I can't find the bit about "servers SHALL support post for all operations."
Sean McIlvenna (Jan 29 2018 at 20:42):
yah... I can't find that bit either
Sean McIlvenna (Jan 29 2018 at 20:43):
this info should be more obvious, somewhere, I think
Grahame Grieve (Jan 29 2018 at 20:44):
well, you can make a task asking for more clarity
Grahame Grieve (Jan 29 2018 at 20:45):
server can support get if it makes sense to only send primitives
Eric Haas (Jan 29 2018 at 20:45):
I'm formulating a GForge .... to clarify this
Eric Haas (Jan 29 2018 at 20:46):
I trust somewhere it says Server's SHALL support POST just can't find it
Sean McIlvenna (Jan 29 2018 at 20:47):
In operationdefinition.html, I see this:
Executing Operations and Named Queries: "operations are executed by POSTing to a URL that is defined by the operation definition. "
Sean McIlvenna (Jan 29 2018 at 20:47):
this kinda makes it sound like POST is all you can do
Sean McIlvenna (Jan 29 2018 at 20:48):
and I see no reference in there to "GET"
Sean McIlvenna (Jan 29 2018 at 20:49):
http://www.hl7.org/fhir/operations.html
Sean McIlvenna (Jan 29 2018 at 20:49):
there's some more in there
Sean McIlvenna (Jan 29 2018 at 20:49):
it focuses, again, on POST scenarios
Sean McIlvenna (Jan 29 2018 at 20:49):
with only a small note about GET
Sean McIlvenna (Jan 29 2018 at 20:49):
"Some Operations with primitive input types and a single Resource output parameter named 'return' can be invoked using a GET directly, with parameters as HTTP URL parameters. In this case, the response is simply the resource that is the return value, with no Parameters resource. These kinds of usage are discussed further below."
Sean McIlvenna (Jan 29 2018 at 20:50):
I think we need a section here that makes it a bit more clear how GET vs. POST is used, and how servers should indicate conformance with GET vs. POST operations.
Rob Hausam (Jan 29 2018 at 21:45):
I'm not surprised. I just replied to your email.
Eric Haas (Jan 30 2018 at 02:35):
Yunwei Wang (Jan 30 2018 at 18:04):
Should server support GET /OperationDefinition/[id] if OperationDefinition profiles are already published on FHIR registry?
Sean McIlvenna (Jan 30 2018 at 18:05):
FYI... this is my original gForge tracker regarding this: https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=14670&start=0
@Eric Haas I mentioned your ticket in the comments of my ticket, as well.
Sean McIlvenna (Jan 30 2018 at 18:06):
@Yunwei Wang , I'm not sure what you mean here... I'm unsure why the operation being published on FHIR registry would impact its implementation.
Yunwei Wang (Jan 30 2018 at 18:12):
@Sean McIlvenna I will clarify my question. Let's say I have a OperationDefinition instance called my-expand-op for $expand operation. I upload this to Simplifier and reference to it in my metedata. Do I still need to provide GET /OperationDefinition/my-expand-op endpoint? Because I can pointing to my metadata and say follow the link to get that operation definition from Simplifier.
Peter Jordan (Jan 30 2018 at 18:13):
I'd expect OperationDefinition instances to be held on the relevant FHIR Server, not an external registry.
Yunwei Wang (Jan 30 2018 at 18:18):
While I treat OperationDefinition instance more like a profile based on base OperationDefinition than a regular resource instance.
Peter Jordan (Jan 30 2018 at 18:19):
I view it more as an extension of the Capability Statement (or will when I actually implement it!)
Grahame Grieve (Jan 30 2018 at 18:43):
@Yunwei Wang - it is perfectly valid to put your operation definition on an external registry and refer to it from your capability statement.
Grahame Grieve (Jan 30 2018 at 18:44):
and if you do this, there is no need to support Get /OperationDefinition on your server
Sean McIlvenna (Jan 30 2018 at 19:39):
@Grahame Grieve , @Yunwei Wang
I mostly agree... However, I think you need to implement the operation definition exactly as defined on the external registry. Otherwise, you run into the same issue that I was discussing earlier about implementing $expand, but only supporting GET, and not supporting POST. In that case, there is no way to tell how much of the operation your server supports.
So, as soon as your implementation deviates or doesn't fully implement the operation definition defined in the external registry, you should support GET /OperationDefinition with your customizations to the operation.
Grahame Grieve (Jan 30 2018 at 19:42):
yes the external opdef has to describe your server. But presumably that's what Yunwei had in mind when he defined his own opdefs on the external server
Sean McIlvenna (Jan 30 2018 at 19:42):
agreed. just wanted to be very clear :)
Peter Jordan (Jan 30 2018 at 19:56):
and if you do this, there is no need to support Get /OperationDefinition on your server
...just assume/hope/pray that the external registry does.
Grahame Grieve (Jan 30 2018 at 20:00):
my favourite kind of repository is the one that allows you to PUT/POST some content, but not GET it
Sean McIlvenna (Jan 30 2018 at 21:30):
lol
Michael Lawley (Jan 31 2018 at 06:50):
@Peter Jordan Note that Ontoserver doesn't support SEARCH on OperationDefinition, but it does support READ on specific ids. These are the ones referenced in the CapabilityStatement. For example, GET http://ontoserver.csiro.au/stu3-latest/OperationDefinition/ValueSet--expand resolves, but GET http://ontoserver.csiro.au/stu3-latest/OperationDefinition does not
Last updated: Apr 12 2022 at 19:14 UTC
