HenrikHL
Frequent Contributor
Joined 5 years ago
User Profile
User Widgets
Contributions
Re: It does not seem like setting a header in a response as required makes any difference
Hi Tom_S , Thank you for the prompt reply :-) When you write: However, for headers, even though they can be defined as required (required: true), Swagger UI does not display a red asterisk or similar indicator for them. This is by design and not an issue with the tool. The required header will still be enforced during validation. I assume you mean required fields on headers in responses - because it works fine for headers in requests:It does not seem like setting a header in a response as required makes any difference
I would expect a little red `*` to appear next to the header-name when I specify the header as a required-header. Here is an example As can be seen - no required "red star" next to the `API Version` header. Is this a bug or just not possible? (According to the schema of a header it should be possible)Re: StopLight "auto"-modifies files
Hi Humashankar No worries - I have already done so. The response from Support is "that is just the way it is" - I was sort of hoping other people also find this annoying and SmartBear could prioritize to fix this... In my PoV it should be an option to turn on/off - whoever wants this can turn it on - and I could turn it off :-)Re: StopLight "auto"-modifies files
Here is an example of StopLight removing newlines and re-indents comments to (in my point of view) a wrong indention: This is how it originally looked (before the push): As you can see the comment has been indented extra to align with line 2086 - but the comment is for the "ErrorResponse" so it makes more sense it is aligned with this... Also annoying that newlines are removed as it makes it easier to read...StopLight "auto"-modifies files
Is it just me or does anyone else find it super annoying that StopLight modifies files when pushing to GitHub. If I have a spec that looks like this: StopLight "automodifies" it to: It also removes newlines that I have deliberately added and changes indention for comments Anybody knows where this can be disabled?Re: The use of oneOf or anyOf in arrays
chichepo no worries - I understood the example 😉 With the autogenerated examples I would assume that: anyOf would generate: "animals": [ { "name": "string", "legs": 0 }, { "name": "string", "owner": "string" } ] and oneOf would generate: "animals": [ { "name": "string", "legs": 0 }, { "name": "string", "legs": 0 } ] (Here the first item in the oneOf would just be repeated twice...) Where in the specifications does it specify that the oneOf or anyOf applies to the entire list and not to each item in the list? My assumption was that below the keyword "items" - the structure for each item in the list is specified. This could be a type:string - in which case all items in the list would have to be of type string. In case it is a oneOf - then each item in the list would be a oneOf... Again - this is just my (maybe wrongly) assumption - it would be great to read an official specification for the use of oneOf and/or anyOf in combination with an array (items field) 🙂
