Forum Discussion
yym
I am trying to make the parameters organization and calls as optimal as possible.
You writed:
"our data models are quite large and rich in parameters that can also be used in a GET requests as query parameters. That is why the query parameters definition in each OAS looks redundant."
I am not sure if it is possible to use such kind of "generic" parameters file, as a reference, as shown in your example.
The construction I suggest is including an API and a dedicated Domain, where I store my "reusable" parameters definitions (API file here and Domain file here).
This is actually the best optimization I can imagine even for huge numbers of parameters.
Don't hesitate to share with us any solutions you could find.
Hi chichepo
Thank you for you suggestions and examples. They were very helpful. I still on my way to find a solution.
First of all, parameters can be the list of Reference Objects.
The second, the Reference Object cannot be extended with additional properties and any properties added SHALL be ignored. Therefore the example in my upper post is incorrect. The field "in" should be removed.
The third, according to $ref Syntax - $ref can be Local Reference, Remote Reference or URL Reference.
Based on this information, I believe it is possible to reference files rather than components section in OAS.
parameters:
- $ref: 'https://<server>:<port>/parameters/queryParameters.json'
- $ref: 'https://<server>:<port>/parameters/headerParameters.json'
- $ref: 'https://<server>:<port>/parameters/pathParameters.json'
Related Content
Recent Discussions
- 28 days ago
- 28 days ago