Support object schemas in responses

[pawamoy]

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: string

It 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 🙂 ?

[dbanty]

@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]

Got it, thank you for the explanation!

[dbanty]

Just realized this is also the same issue as #140, not sure how I didn't see that one before.

[dbanty]

Oh jeez and also #125. I guess I really ought to implement this one.

[dbanty]

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]

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 OperationIdResponse or OperationIdBody or OperationIdBodyPropertyName.

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_overrides config property if they need to.