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

Deprecate Parameter.content in favor of JSON Schema's contentSchema? #2289

Open
hkosova opened this issue Jul 16, 2020 · 1 comment
Open
Labels
media and encoding Issues regarding media type support and how to encode data (outside of query/path params)

Comments

@hkosova
Copy link
Contributor

hkosova commented Jul 16, 2020

JSON Schema 2019-09 has the contentSchema keyword whose purpose and functionality seems to be the same as that of content in Parameter Objects.

Should Parameter Object's content be deprecated in favor of JSON Schema's contentSchema keyword?

Example:

# Query parameter representation before URL encoding
?data={"foo":"hi","bar":123}

OAS 3.0:

parameters:
  - in: query
    name: data
    content:
      application/json:
        schema:
          type: object
          properties:
            foo:
              type: string
              example: hi
            bar:
              type: integer
              example: 123

OAS 3.1 + contentSchema:

parameters:
  - in: query
    name: data
    schema:
      type: string
      contentMediaType: application/json
      contentSchema:
        type: object
        properties:
          foo:
            type: string
            example: hi
          bar:
            type: integer
            example: 123
@handrews
Copy link
Member

@hkosova the use cases definitely match here, as parameters are by definition strings, and any other aspect of their structure is encoded into the string.

However, I remember running into some sort of trouble trying to square the usage of Media Type Objects, Encoding Objects, and the content* keywords for multipart requests/responses and/or file uploads.

Another potential wrinkle is that normally you'd expect a JSON string, and therefore need to decode escaped double quotes and backslashes as you parsed the JSON value (but nothing else that's a legal JSON character would need decoding). In this case, the string needs to be parsed/decoded according to URI query string rules, which are somewhat different. I think it is acceptable to wave our hands here a bit and say that the context (parameter object with in: query) is how you determine how to decode the string. (This whole paragraph is me thinking out loud, if it's not entirely clear I'm happy to answer questions but it might just be that I'm still thinking through it.)

@handrews handrews added the media and encoding Issues regarding media type support and how to encode data (outside of query/path params) label Jan 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
media and encoding Issues regarding media type support and how to encode data (outside of query/path params)
Projects
None yet
Development

No branches or pull requests

2 participants