I’ve created an API based on a valid OpenAPI definition. From this, I created a collection, which I note is under the API, not Collections.
When I send a request and get a response, I immediately get a warning for several headers, like:
The header Server was not found in the schema
The header Date was not found in the schema
The header Access-Control-Allow-Origin was not found in the schema
Etc. I admit I did not define these in the response section of my API definition. But that’s because they are not important to API development.
How do I get rid of these warnings?
I think the simplest would be to disable this check, but I only see a way to disable request validation (which I want), not response. I don’t see a way to automatically add the missing headers to my definition. I checked the OAS/Swagger (v3) docs and they confess there is no way to define response headers that are common to all operations - you literally have to copy them to every single response block. I suspect they agree these headers are unimportant.
I do note I only get these errors if the collection is under the API, where I think it should be. If it is under Collections, no errors are reported, presumably because no checking is being done at all.
Is there any good solution to this? I’m a fan of validation and of generating collections from the API, but two way syncing would really be ideal. Please let me know if I missed something in the docs. Thanks!
Thank you for sharing your concerns. This is a common challenge that many face when validating against OpenAPI Schemas.
Response Headers Warning: When you validate a response in Postman against your OpenAPI definition, it checks for completeness. This means even headers like Server, Date, and Access-Control-Allow-Origin, which might not be central to your API functionality, are considered in the validation.
Disabling Specific Validation: Currently, Postman offers the ability to disable request validation. However, it doesn’t provide a granular setting for skipping specific header validations in the response.
Defining Headers in OpenAPI: To bypass these warnings while still using validation, you’ll need to include these headers in each endpoint’s OpenAPI definition. Yes, it can be a bit tedious, especially if these headers are shared across several endpoints.
Collection’s Position and Validation: You observed correctly. When a collection resides directly under “Collections”, it won’t enforce the validation checks against the OpenAPI schema. This behavior stems from the fact that the linkage between the collection and the API schema isn’t as tightly bound as when it’s nested under an API.
Recommendation: If strict adherence to the OpenAPI spec isn’t crucial for you, you might consider keeping your collection under “Collections” to avoid the additional header warnings. On the other hand, if you want a strict validation, incorporating the headers into your OpenAPI definition is the current workaround.
For enhancements like granular control for response validation, we value community input. Please consider submitting a feature request on our GitHub repository so it can be discussed and tracked.
Thank you for using Postman and for your constructive feedback!
