Skip to content

Share header with multiple response objects #369

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

Open
huangsam opened this issue May 19, 2015 · 11 comments
Open

Share header with multiple response objects #369

huangsam opened this issue May 19, 2015 · 11 comments
Labels
re-use: globals/defaults Default or global components that can be overridden in some way

Comments

@huangsam
Copy link

Can there not just be a simple header generically at the response level not specific to each of the status codes? For our case, this kind of header is 99% the same across our codebase.

---

responses:
  200:
    description: no error
    headers:
      Content-Type:
        description: application/json
        type: string

It would be a pain to copy+paste this to each and every routine that supports HTTP JSON responses.

@webron
Copy link
Member

webron commented May 20, 2015

Unfortunately, no. The headers in the responses is actually a new feature in 2.0, and we hadn't thought of the option to allow a global definition for it.

@RobDolinMS
Copy link
Contributor

@webron Given your response above, should we close this issue? /cc @huangsam

@webron
Copy link
Member

webron commented Apr 26, 2017

It's still an option we might consider in future versions.

@whitlockjc
Copy link
Member

Isn't this handled in 3.0 You define your reusable headers at #/components/headers and then use a $ref to reuse it. It won't allow you to have a singular reference to define all common headers in a response but then you could probably use #/components/responses for that.

@webron
Copy link
Member

webron commented Apr 26, 2017

Yeah, but this is not about reusability (which makes it easier) - it's about declaring it only once for all.

@darrelmiller
Copy link
Member

What happens when someone declares a Content-Type header for all responses and then adds a 204 response?

@webron
Copy link
Member

webron commented Apr 27, 2017

@darrelmiller did we not just talk today about disallowing Content-Type headers? :)

@darrelmiller
Copy link
Member

@webron Fine: content-length, Transfer-encoding, Range, ... how obscure do I need to get? :-)

@michael-o
Copy link

Obviously the example is bad. consider the following model:

paths:
  /api/v1/modules:
    get:
      tags:
        - Modules
      summary: Lists all available modules
      operationId: listModules
      responses:
        200:
          $ref: "#/components/responses/modulesOk"
        400:
          $ref: "#/components/responses/400"
        401:
          $ref: "#/components/responses/401"
        403:
          $ref: "#/components/responses/403"
        404:
          $ref: "#/components/responses/404"
        406:
          $ref: "#/components/responses/406"
        408:
          $ref: "#/components/responses/408"
        500:
          $ref: "#/components/responses/500"

Codes like 401, 403, 404, 406, 408 will repeat through all paths. If one could add this to a generic section and selectively overwrite it, it'd be great. Having 50 paths and adding that block over and over again ist just pain.

@guptaashwanee
Copy link

Is this still not available in the schemas? This will be the great feature and I was also looking for this for a long time.

@msolujic
Copy link

let use this discussion to underline two common issues and possible enhancements regarding response headers:

  1. having a way to define common response headers for some API once and override only some of them if needed
  2. we miss the ability to include multiple headers in one $ref, and not being forced to have 8 refs for 8 headers each and every time

is this planned for some future OAS spec?

@handrews handrews added re-use re-use: globals/defaults Default or global components that can be overridden in some way and removed re-use labels Jan 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
re-use: globals/defaults Default or global components that can be overridden in some way
Projects
None yet
Development

No branches or pull requests

9 participants