Skip to content
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

Global/common parameters #341

Closed
noirbizarre opened this issue Apr 26, 2015 · 6 comments
Closed

Global/common parameters #341

noirbizarre opened this issue Apr 26, 2015 · 6 comments

Comments

@noirbizarre
Copy link
Contributor

Global parameters are common in API definition.
Authentication paramters were made specifics with the security property but there is no way to define global common paramters.

Most of the time global parameters are business-less parameters and it make sense to define them globally.

I know it's possible to define reusable parameters through the root parameters property but it's not the same thing, it does not respond to the need.

I have a lot of entry point in the API and I don't want to repeat parameters like lang, pretty or fields which are global and not functionnaly related to each endpoint.

Is there a way I'm not aware to do that like a globalParameters property ?

If not, is it possible to add that for the next specification release as it's a common use case.

@webron
Copy link
Member

webron commented Apr 26, 2015

One problem with that feature is that users may then request a way to 'ignore global parameters' and that's going to complicate things. We've thought about adding it to 2.0 but it was rejected.

That said, it does not mean it shouldn't be a proposal for the next version.

@noirbizarre
Copy link
Contributor Author

I understand. But maybe it should be explicit that's only non ignorable parameters, API-wide parameters.

I will be glad if this can be proposed proposed and discussed for the next version.

I agree, there shouldn't be a way to ignore these: it's over-complicated and most of the time it's bad usage of global parameters (if someone have a counter example)
Global parameters shouldn't be considered as a facility to avoid repetition, but as real global parameters independent from the business, so not overridables.

I maintain multiple APIs and it's a very common and recurrent use case (with at least the following examples: lang, pretty, fields, format, ...).
Each time they have the following attributes:

  • optional query-string parameter, have a sane default value.
  • non-business related (it does not modify the functionality of operations)
  • transport or format related
  • technically, they are not handled by the same piece of software, so difficult to declare on every operation in code-to-specs approach

Each time, having to repeat them on each operation has the following side-effects:

  • make the specifications a lot bigger
  • make the operations harder to read
  • impose to mix business and transport/format
  • impose to trick server side to handle them properly (in the case ware specifications are generated from the code) leading to over-engineering, more complexity

If some want to ignore a parameter on an operation, it should be seen as "rare exception" and shouldn't prevent the existence of global parameters in the specifications.
For them, I would say it's easier to set optionnal parameter or parameters with default value and on the ignoring operation, simply add a note that the parameter won't have effect.

@4thex
Copy link

4thex commented Dec 12, 2015

Perhaps if the parameters were linked with a tag, it could apply to all operation objects with the same tag. If the tag was left out, it would be global.

@webron
Copy link
Member

webron commented Mar 18, 2016

Parent issue: #560.

@fehguy
Copy link
Contributor

fehguy commented Apr 11, 2016

Closing in favor of #633

@fehguy fehguy closed this as completed Apr 11, 2016
@hkosova
Copy link
Contributor

hkosova commented Aug 24, 2017

Why is this closed? #633 (components object) is not the same as global parameters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants