Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
@OperationParam handling feels incorrect #317
I'm wondering why DataTypes needs to be provided as parameters for extended operations rather than subclasses of BaseParam just like in @Search methods. The code in OperationParameter#initializeTypes also looks quite inconsistent with regard to this (e.g. why DateRangeParam is allowed, but no other Params...)
Related to this, there is also a potential misconception about what complex vs. primitive parameters are with respect to allowing them for GET operations. According to https://chat.fhir.org/#narrow/stream/implementers/topic/operations.20with.20%27complex%27.20parameters, e.g. a TokenParam is not considered complex although carries more than a single primitive value.
For implementing operations with TokenParams, I need to work around this by providing a StringType parameter and split the string at the pipe into system and value part. Feels very hacky...
This is very timely really.
The main reason for the use of datatypes instead of search parameter types is that the "parameters-inthe-URL" syntax for calling operations is just a shortcut for the more formal way, which is sending in the values in a Parmeters resource. Since you need to be able to send in values as fields in a resource instance, the values need to be datatypes.
Grahame has always expressed a preference that we should be able to use search parameter types too, but it was never clear how this would translate to the parameters resource. The FHIR Infrastructure group finally voted on this about a month ago maybe, and the values will be represented as String types in the Parameters.
So this means HAPI needs to catch up. I'd agree you should be able to use all the same types on operations, e.g. StringParam, TokenParam. I spent some time on a train ride this morning getting that working, so I'll check that in shortly.
Not sure if this adds to this issue...