-
Notifications
You must be signed in to change notification settings - Fork 11
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
Validate format constraints on string properties as described in OpenAPI 3.0 spec #374
Comments
@daffinm , thanks for logging this. Please apply the "OpenAPIv3" label to these issues, as I've done on this one. |
…in OpenAPI 3.0 spec Modified schema to validate email property
PR #415 shows how to add email validation. |
In PR #415 I put some screencasts showing the current state of url/email validation. Those work in the v2 editor because the v2 schema includes the format But as shown in the screencasts the validation of url values may be not what we expect (for example a value The OpenAPI v3 specification states that those properties should be valid URL. If that means that in this case URI should not be considered, then we could implement our own URL validator (that uses java.net.URL instead of java.net.URI). Or we could consider the current validation sufficient and only adds the missing |
@ghillairet, I didn't read the entire background on URI vs. URL. But another aspect of this is relative vs. absolute URIs / URLs. Assuming relative URLs are allowed, something like "foo" might actually be valid, syntactically. In general. I don't think it's worth implementing our own validation for URL syntax. Where the URL is used as part of a Reference Object (or other reference-object-like construct), we have the additional validation to ensure that the URL resolves to a valid object of the expected type. I think that covers the most important cases for us. |
[#374] Validate format constraints on string properties as described …
Just looking at this again as I prep the new release. In the following code sample the values are all direct quotations from the spec. I now get 2 errors instead of none. But I am expecting to see 4, perhaps 6 errors in total: The contact url and email errors are spot on. But what about errors for info/termsOfService & license/url? (The other two are possibilities. Is a sentence value for openapi really valid?) Note also that the spec clearly says URL and not URI. Why can't we just use a regex? |
I think
URLs are what we discussed in this PR, above. I'm open to trying a regex as our own custom validation of URL-format string properties. But I really don't want to burn a lot of development time or support time on this. If we think the URL regex will be foolproof, OK, let's try it. |
For example, the following fragment gives no warnings or errors and yet it is not legal according to the specification.
@tedepstein comments:
The text was updated successfully, but these errors were encountered: