-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add compartment variants to generated swagger / openapi #1846
Comments
Signed-off-by: Troy Biesterfeld <tbieste@us.ibm.com>
Signed-off-by: Troy Biesterfeld <tbieste@us.ibm.com>
Signed-off-by: Troy Biesterfeld <tbieste@us.ibm.com>
Signed-off-by: Troy Biesterfeld <tbieste@us.ibm.com>
Issue #1846 - Add compartment variants to generated swagger/openapi
I loaded the all-in-one-swagger that we publish with the server by navigating to https://localhost:9443/openapi/ui and I can see the compartment variants under the appropriate resources. I discussed with @tbieste about whether it makes more sense to have all the compartment-related endpoints grouped under their compartment header, but we decided to keep it this way because otherwise those compartment sections are so long that its easy to get lost on the UI. I also verified that, when a filter is passed, only the desired resource endpoints are added to the compartment definitions. Further, I confirmed that when all Patient compartment resources are filtered out, the tool skips generation of the Patient compartment swagger definition altogether. Looks good! |
Is your feature request related to a problem? Please describe.
The IBM FHIR Server supports accessing data via compartment search as defined at https://www.hl7.org/fhir/http.html#vsearch
However, these variants are not listed in our generated swagger / openapi definitions
Describe the solution you'd like
Generated swagger / openapi definition should include these endpoints.
In the case that users have filtered the resource types to include, include only the passed resource types in the compartment.
In the case of the one-definition-per-resource-type case, I think we should generate 1 definition per compartment.
For example,
patient-swagger.json
would only have the current Patient-scoped operations (e.g.GET Patient/[id]
) and we'd have a separate definition likepatient-compartment-swagger.json
which would have the compartment operations likeGET Patient/[id]/Observation
Describe alternatives you've considered
Instead of 1 definition per compartment, we could list the compartment apis underneath the generated api definition for the compartment resources. For example, the patient-swagger.json would have both
GET Patient/[id]
andGET Patient/[id]/Observation
.Additional context
Add any other context or screenshots about the feature request here.
Suggestion for how to perform QA
The text was updated successfully, but these errors were encountered: