Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Structural improvements: enhance headers handling

See original GitHub issue

Following (again) ideas from #563 and #684, extending #369:

define reusable response headers (like parameters or definitions as proposed in #563 by @fehguy )
set responses headers on each level: whole api, path, operation, responses (and response as stated in #369)

paths:
  responseHeaders:
     # Headers returned on all api responses
  /resources:
    responseHeaders:
      # Headers returned on all /resources operations responses
    get:
      responseHeaders:
        # Headers returned on all operations responses
      200:
         headers:
           # Headers returned on this response
schemas:
  responseHeaders:
    # reusable headers describe with a Header Object, used with $ref

The problem is the naming consistency: responseHeaders almost everywhere vs headers on response level. What if we use headers or responseHeaders everywhere?

nb: and don’t forget to modify Header Object to include #321 (required)

Issue Analytics

State:
Created 7 years ago
Reactions:28
Comments:11 (3 by maintainers)

Top GitHub Comments

6reactions

etoewscommented, Jun 9, 2016

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.

2reactions

n-alex-whitecommented, Jun 16, 2020

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?