Repository navigation
Support object schemas in responses #162
Description
I am not sure what is happening here, so opening this as a question.
I have this response defined in my spec file:
responses:
'200':
description: Some description
content:
application/json:
schema:
type: object
properties:
Message:
description: Success message or informations in case of failure
type: string
Status:
description: Indicates if the insertion was a success or a failure
type: stringIt gives me the following warning when generating a client (I removed all the None fields and indented properly):
ERROR parsing POST /api/v1/my-api/versions/{versionID}/reference-file within default. Endpoint will not be generated.
cannot parse response of endpoint my_endpoint
Response(
description='Some description',
content={
'application/json': MediaType(
media_type_schema=Schema(
type='object',
properties={
'Message': Schema(
type='string',
description='Success message or informations in case of failure'
),
'Status': Schema(
type='string',
description='Indicates if the insertion was a success or a failure'
)
}
)
)
}
)Do you have an idea why this cannot be parsed or transformed as code? What am I doing wrong in my spec 🙂 ?
Activity
dbanty commentedon Aug 17, 2020
@pawamoy you didn't do anything wrong, it looks like we just don't support inline object schemas in responses, only references. Responses are still pretty limited, the plan is to ultimately share more of their logic with the input properties but I haven't gotten around to that yet. This is the same idea as #93 though I probably need to make a more general issue for combining the logic.
This could also be alleviated by #115 so if we haven't added support for a type of response yet you can get the raw version.
pawamoy commentedon Aug 17, 2020
Got it, thank you for the explanation!
dbanty commentedon Aug 18, 2020
Just realized this is also the same issue as #140, not sure how I didn't see that one before.
[-]Cannot parse response[/-][+]Support object schemas in responses[/+]dbanty commentedon Aug 18, 2020
Oh jeez and also #125. I guess I really ought to implement this one.
dbanty commentedon Sep 26, 2020
I pinned this issue just because it's a very common one to duplicate, so hopefully adding a little visibility will reduce the duplication.
dbanty commentedon Oct 3, 2020
Plan is to name generated classes the same way suggested in #191. There are several different places a generic object can appear, so it'll vary a bit how to try to auto-name it, but generally it will be prefixed with some identifier of the component it's inside of. This might be
OperationIdResponseorOperationIdBodyorOperationIdBodyPropertyName.These can get pretty ugly pretty fast with nesting but I think it's best to be explicit and unique and allow users to override class names using the existing
class_overridesconfig property if they need to.