-
Notifications
You must be signed in to change notification settings - Fork 9.1k
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
Add support for patternProperties in schemas #687
Comments
It also allows having several patterns with each a different value schema: type: object
patternProperties:
'^[A-Z]{2}$':
type: integer
description: the population of the country indicated by the property name.
'^[A-Z]{3}$':
type: string
description: the name of the airport with the given IATA airport code. I suppose this was deemed as too complicated to map to statically typed programming languages when choosing which features from JSON schema to use in Swagger 2.0. (I still can not imagine how a schema like this would be mapped to a Java class.) |
Tackling PR: #741 |
👍 |
For java, if you add another key type: object
patternProperties:
'^[A-Z]{2}$':
type: integer
name: population
description: the population of the country indicated by the property name.
'^[A-Z]{3}$':
type: string
name: airports
description: the name of the airport with the given IATA airport code. request.getPatternProperty("population") <- Map<String, Integer>
request.getPropertyPattern("airports").put("DEN", "Denver International Airport") |
No, |
So, how can we help get patternProperties into the OAS spec? The lack of this is really hampering our ability to express our response objects in OAS. Use case: We have an API that allows a customer to ask "what do you know about these things?", where things can be of different types. We use the values passed in as the keys in the response to say "here's what we know about this item". |
I would also be keen on having this feature because this could make the json a bit shorter for swagger examples. The property name could be an "id" in our case. That could be described by a simple regexp. |
Could we get the 3.1 label on this? |
Would that be necessary if we have |
It's worth figuring out what should happen with the almost-JSON-Schema dialect going forward. Obviously it cannot be removed in 3.x, although I would argue for removing it in 4.0 because it is burdensome for new tools to implement. In the meantime, I'd rather focus on getting |
This does raise the question: What is the @handrews if the current schema is removed, then its only alternate schema, meaning whats the alternate about. Would you see OAI moving to promote Or @MikeRalphson is it more likely OAI will be keeping this OpenAPI Schema Object around indefinitely, meaning there will forever be this custom "like JSON Schema but not" format supported as core, with alternates floating around too? If the latter, is there any interest in trying to close some of the gaps between JSON Schema and OpenAPI Schema Object, in a backwards compatible way? I can understand not deleting stuff, but adding some of the excellent functionality that JSON Schema has been adding is going to help OpenAPI users, no? |
Btw this needs to be merged whatever happens. #1521 |
@philsturgeon I think the end result depends a lot on the popularity of |
Any updates on this - badly needed. Or is there a workaround or alternative? |
@sweepy84 got the same issue and found out that link:https://philsturgeon.uk/api/2018/04/13/openapi-and-json-schema-divergence-solved/ It may help you for fitting the current spec |
@hkosova pointed out to me, this can be closed as implemented in OAS 3.1. |
…allows for variable keys in an object the API returns keys that are service IDs, but this spec will currently match any string keys. openapi spec 3.1 will include "patternProperties", which will allow us to specify the format of keys see OAI/OpenAPI-Specification#687
If this is implemented in 3.1, could you link to the spec where |
@ctrl-f5 OAS 3.1 supports all of JSON Schema drafts |
I am struggling to find this too. |
Seeing as the Schema Object in OpenAPI v3.1 is a valid JSON Schema object, they've not needed to re-define everything in OAS, instead you can look at the JSON Schema spec or use their tutorials. https://json-schema.org/understanding-json-schema/reference/object.html#patternproperties |
JSON Schema draft 4 has
patternProperties
which is not supported by Swagger 2.0.patternProperties allows to have loosely defined objects where the list of keys is not fixed in the spec (like
additionalProperties
allows in Swagger 2.0), but the format of the keys is restricted with a regexp (contrary toadditionalProperties
where keys are not at all limited).Here is a use case from #380:
The text was updated successfully, but these errors were encountered: