Skip to content
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

Nested object schema validation in query params #83

Open
hendrikheil opened this issue May 7, 2024 · 2 comments
Open

Nested object schema validation in query params #83

hendrikheil opened this issue May 7, 2024 · 2 comments

Comments

@hendrikheil
Copy link

Given my understanding of JSON schema and OpenAPI (3.1) the following schema is supposed to be valid:

paths:
  /path:
    get:
      parameters:
        - name: obj
          in: query
          style: deepObject
          schema:
            type: object
            properties:
              root:
                type: string
              nested:
                type: object
                properties:
                  child:
                    type: string
          required: true

Meaning an URL like /path?obj[root]=test1&obj[nested][child]=test2 should pass the validation against the schema above.

As far as I can tell from the code deepObject style query parameters are decoded to a flat map of QueryParam arrays. This works for objects with a depth of one, but won't work for objects with more depth.

@hendrikheil
Copy link
Author

hendrikheil commented May 7, 2024

Since this type of notation isn't really standardized anywhere, I think the current behavior is generally not wrong.

OpenAPI 3.1 makes no remarks about the level of nesting, where as 3.0 does specify only a single level of nesting.
But in general, there is an ongoing discussion: OAI/OpenAPI-Specification#1706

Since behavior isn't well defined, I think it might still be a good idea to implement the "qs" style of notation, since nested object schemas are generally definable in OAS 3.x.

However, there is a workaround to this issue, which is just flattening the object keys.

paths:
  /path:
    get:
      parameters:
        - name: obj
          in: query
          style: deepObject
          schema:
            type: object
            properties:
              root:
                type: string
              nested[child]:
                type: string
          required: true

I don't think it has the exact same semantics and definitely doesn't allow as fine grained of a control as one would have with using object type schemas, but I think it is decent enough for a lot of cases.

@daveshanley What do you think about this? Worth keeping it open or should this be closed and the behavior stay as is?

@daveshanley
Copy link
Member

I have not spent a huge amount of time here in deeply nested deepObject encoding (it seems like a anti-pattern to me) however I do think there is value is growing support for it, as I have seen this type of design a few times and there is a need to support it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants