Skip to content

Add support for yang-data+json content type #706

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

Closed
wants to merge 1 commit into from

Conversation

XioNoX
Copy link

@XioNoX XioNoX commented Dec 6, 2022

Fix error

WARNING parsing GET /restconf/data/ietf-snmp:snmp within ietf_snmp.

Cannot parse response for status code 200 (Unsupported content_type {'application/yang-data+json': MediaType(media_type_schema=Reference(ref='#/components/schemas/get_ietf_snmp_snmp'), example=None, examples=None, encoding=None)}), response will be ommitted from generated client

When using SONiC OS REST OpenAPI.

Fix error
```
WARNING parsing GET /restconf/data/ietf-snmp:snmp within ietf_snmp.

Cannot parse response for status code 200 (Unsupported content_type {'application/yang-data+json': MediaType(media_type_schema=Reference(ref='#/components/schemas/get_ietf_snmp_snmp'), example=None, examples=None, encoding=None)}), response will be ommitted from generated client
```
When using SONiC OS REST OpenAPI.
@dbanty
Copy link
Collaborator

dbanty commented Dec 7, 2022

Is there a standard we can follow for generic JSON-like response types? Should anything +json be considered JSON?

@codecov
Copy link

codecov bot commented Dec 7, 2022

Codecov Report

Merging #706 (106ceb1) into main (17373e0) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main      #706   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           49        49           
  Lines         1954      1954           
=========================================
  Hits          1954      1954           
Impacted Files Coverage Δ
openapi_python_client/parser/responses.py 100.00% <ø> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@XioNoX
Copy link
Author

XioNoX commented Dec 8, 2022

Is there a standard we can follow for generic JSON-like response types? Should anything +json be considered JSON?

That would make sens to me but I'm not aware of such standard.

@mtovt
Copy link
Contributor

mtovt commented Dec 17, 2022

Hi there! Not sure if this is the standard we are looking for but this one looks like something we need 4.2.8 Structured Syntax Name Suffixes.

OpenAPI spec also has section Media Types.

@dbanty
Copy link
Collaborator

dbanty commented Dec 17, 2022

Thanks @mtovt, that's exactly the sort of thing I was looking for! Cool, I'm going to replace this PR with one which accepts anything ending with +json as a valid alternative to application/json.

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

Successfully merging this pull request may close these issues.

3 participants