-
Notifications
You must be signed in to change notification settings - Fork 86
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
type+format error on allowable combination (format: uuid) #19
Comments
I think we should be letting users know when they aren't using an explicitly defined format but an @mkistler What are your thoughts? |
The OpenAPI spec allows any value for |
@mkistler Because it is allowed, I think it should be marked as a warning, not an error. |
That's not the criteria that we use to decide error vs warning. There's a long list issues we flag as errors that are allowed by the spec.
We flag things as errors when they are 1) common sources of error, 2) generally correctable without huge effort. Arbitrary values in "format" have been very common in WDC API docs and they cause significant problems in the SDKs, since they result in incorrect types for parameters or properties. I know of no strong argument for using non-standard "format" values, and I am unaware of any effort that is needed to change them other than to edit the API doc. |
@mkistler Perhaps it would be better to allow users to whitelist some format types? In case 'I know what I am doing'. |
We will be adding some types -- specifically Re: "I know what I am doing", I think the more important question is: "Does everyone know what you are doing?" |
Well, it depends on particular situation. In my case we use Marshmallow which has explicit uuid type of schema field and write docs in Openapi format for internal use. In such situation uuid format looks ok. May be when we publish the API to the outer world it will be not true, but now 'everyone knows' :) |
@mkistler We use |
@bartkummel I think we'd be open to a configuration option for this. That might be tricky to design in a general manner, but we could start with something that enables your use case and grow it from there as needed. Maybe a configuration like:
Another option is to disable the |
@mkistler Exactly. I've disabled the rule for now, but it would be nice to have something like you suggest. |
What do you think if extract to config all allowed type+format pairs for primitive types? Like
e.g. for cases of using ahead OAI/OpenAPI-Specification#845 |
@apestov I assume your example is the default then? So we can add e.g. |
@bartkummel It's more like a proposal that may (or may not) feet the openapi-validator project approaches. |
@apestov Sure, that's how I interpreted it. |
I think I would prefer an approach that only extended the list of allowed type+format values. There is a well-defined set of type+format pairs in the spec, and I don't see any value in generating messages for any of these. So a design that would let the user (in all likelihood unintentionally) drop these from the "allowed" list only creates an opportunity for people to shoot themselves in the foot. |
That make sense. |
Could someone point me at a doc or give a pointer as to the best openapi v3 way to define fields as UUIDs using the standard "5 groups separated by hyphens, in the form 8-4-4-4-12 for a total of 36 characters" format so that the "Property type+format is not well-defined." error is not raised? Is this possible right now in Openapi v3? |
You could use a |
Thanks @mkistler - I completely missed that in the Swagger docs here: https://swagger.io/docs/specification/data-models/data-types/#pattern |
Because the validator allows only the formats that are listed in the specification table, it produces an error for some that are usable. For example,
"format": "uuid"
.https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#data-types
https://swagger.io/docs/specification/data-models/data-types/
error
source
The
trace
use case is from our API Implementation Handbook about errors.The text was updated successfully, but these errors were encountered: