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
Structural improvements: enhance headers handling #690
Comments
parent #560 |
Can't put my finger on it, but something here seems tricky when it comes to the resolution of the 'effective' spec. Multiple levels of being able to define both headers and responses (which can define the headers as well)... feels like a recipe for trouble. I'm probably overthinking it though. |
Being able to define reusable response headers in someway is a necessity. Having to constantly repeat yourself for response headers is a significant maintenance burden. |
Sounds like a great idea, maybe even generalize it even more to use refer to definitions-like item from various places for reuse. |
Absolutely a great idea and a must have. Currently we hare facing issues where we have to copy paste headers across all APIs which makes for error prone updates and maintainability issues. The key flexibility would be able to reference the headers and in addition specifying headers at a global level would help clean up the spec. |
I agree, some means of defining standard headers to be applied to all the requests and responses in a swagger definition would be exceptionally useful. At the moment an API definition I'm working on has been bloated by 1,300 lines by the need to include the same additional headers for each response code on each API member. it obscures the intent and provides maintenance problems; it is crying out for the ability to reference standard sets of headers IMO. |
I'm in the process of trying to define a API now and the thought of adding the rate-limit headers to every single response definition is already making me want to pack it in. This really needs to happen,. |
@synackSA Personally, I would define a 429 response in I've never quite understood why APIs choose to return rate limiting headers on successful responses. Do client applications actually read those values and hold off on making requests until they know the reset period has ended? Is there some other function that makes them useful? |
As a reference: our Jenkins setup has a feature where it "scrapes" our organisation's repositories and checks all branches for a valid Just wanted to chime in that apparently, there are valid use-cases for these headers 👍 |
I'm personally not sure if will or won't but they can't blame us for not providing the information to them, it's up to them to actually implement it, either way, they will get rate limited if they it their limit. All the info is there for them to manage it otherwise. |
Four years on, are we any closer to getting response headers definable as components in the same way that request headers are? Is there anything that can be done to help move this issue forwards somehow? |
@n-alex-white It's possible to reference re-usable response headers under |
Following (again) ideas from #563 and #684, extending #369:
The problem is the naming consistency:
responseHeaders
almost everywhere vsheaders
on response level.What if we use
headers
orresponseHeaders
everywhere?nb: and don't forget to modify Header Object to include #321 (required)
The text was updated successfully, but these errors were encountered: