FHIR Chat · CapStmnt.rest.operation.name v OpDef.code

Stream: implementers

Topic: CapStmnt.rest.operation.name v OpDef.code

Lee Surprenant (Nov 03 2021 at 14:40):

I'm almost certain that I've asked this, but now I can't seem to find it...
If the CapabilityStatement.rest.[resource.]operation.name doesn't match the OperationDefinition.code, clients should use the CapabilityStatement.rest.[resource.]operation.name in the URL of their requests, right?

Lee Surprenant (Nov 03 2021 at 14:43):

I know for a fact that this is how it works for SearchParameter definitions... the definition is just that...what matters is the name in the CapabilityStatement.rest.resource.searchParam.name (per FHIR#27755)

Lee Surprenant (Nov 03 2021 at 14:46):

My assumption is that the same holds true for operations, but if so then bulk data IG has this wrong

Lee Surprenant (Nov 03 2021 at 14:47):

The spec says this for OperationDefinition.code:

Name used to invoke the operation

But then it says this for CapabilityStatement.conformance.rest.operation.name

Definition:
The name of the operation or query. For an operation, this is the name prefixed with $ and used in the URL. For a query, this is the name used in the _query parameter when the query is called.

Comments:
The name here SHOULD be the same as the name in the definition, unless there is a name clash and the name cannot be used. The name does not include the "$" portion that is always included in the URL.

Lloyd McKenzie (Nov 03 2021 at 14:55):

Operations work like search parameters. There's a default code that should be used. However, because they're not globally unique, a server can implement a different name for some operations or search parameters to avoid collisions.