Support multiple content types for a single endpoint

[dpursehouse]

With an openapi yaml schema that has this content:

      requestBody:
        content:
          application/json:
            schema:
              type: array
              items:
                $ref: '#/components/schemas/REDACTED'
          application/x-www-form-urlencoded:
            schema:
              type: array
              items:
                $ref: '#/components/schemas/REDACTED'
          multipart/form-data:
            schema:
              type: array
              items:
                $ref: '#/components/schemas/REDACTED'
        required: true

The generated client has this method:

def _get_kwargs(
    *,
    client: AuthenticatedClient,
    multipart_data: List[REDACTED],
    json_body: List[REDACTED],
) -> Dict[str, Any]:
    url = "{}/api/redacted/".format(client.base_url)

    headers: Dict[str, Any] = client.get_headers()
    cookies: Dict[str, Any] = client.get_cookies()

    json_json_body = []
    for json_body_item_data in json_body:
        json_body_item = json_body_item_data.to_dict()

        json_json_body.append(json_body_item)

    multipart_multipart_data = []
    for multipart_data_item_data in multipart_data:
        multipart_data_item = multipart_data_item_data.to_dict()

        multipart_multipart_data.append(multipart_data_item)

    return {
        "url": url,
        "headers": headers,
        "cookies": cookies,
        "timeout": client.get_timeout(),
        "files": multipart_multipart_data,
    }

The diff from the client generated by version 0.9.2 is that it now takes a multipart_data parameter which is now used to populate the files field on the returned dict.

However the json field was removed and the json_body parameter is thus unused. This breaks clients that are passing the json_body field.

Adding it back fixes it, i.e.

    return {
        "url": url,
        "headers": headers,
        "cookies": cookies,
        "timeout": client.get_timeout(),
        "json": json_json_body,          # <--- HERE
        "files": multipart_multipart_data,
    }

[dbanty]

Interesting, I don’t think we’ve ever added (at least intentionally) support for multiple content types in one endpoint. How do you think this would be most ergonomic in the generated client? Only one content type can actually be sent so the function definition should indicate that somehow.

Should there be a separate function per content type? Or maybe function overloading?

[dpursehouse]

Maybe make both parameters optional, and then raise an exception if both are set, or if neither is set?

[dpursehouse]

@dbanty it turns out that this could be solved by explicitly setting parser_classes = [JSONParser] in the Django view, which prevents the schema generated by drf-spectacular from including the multiple content types.

[dbanty]

Glad you found a solution @dpursehouse! Would still love to add support for this some day, I'm sure there are others who would benefit from it.

[johnthagen]

@dpursehouse

it turns out that this could be solved by explicitly setting parser_classes = [JSONParser] in the Django view,

Do you know if this breaks the DRF Web browsable API? (e.g https://www.django-rest-framework.org/ | Web Browsable API: https://restframework.herokuapp.com/) I assumed that the form_data portion was used by the browsable API, and disabling form_data could have unexpected consequences?

[johnthagen]

However the json field was removed and the json_body parameter is thus unused. This breaks clients that are passing the json_body field.

@dbanty It seems like this portion might be a bug in its own right.

When I wanted to send json_body information in a Patched request (all fields are optional and default to UNSET in the generated client code), this didn't work:

        t_partial_update.sync(
            metal.id,
            client=client,
            json_body=T(type="RED"),
            form_data=T(),
            multipart_data=T(),
        )

I opened up Wireshark on localhost interface to confirm and all of the PATCH requests that are sent are blank (no data).

I had to move it to the form_data parameter to get the data to be sent, but this seems a bit misleading/counter intuitive:

        t_partial_update.sync(
            metal.id,
            client=client,
            json_body=T(),
            form_data=T(type="RED"),
            multipart_data=T(),
        )

[dbanty]

I assume this is a limitation in httpx but it'd take some testing to be sure. Sending both a form and JSON is quite unusual. I'm guessing it just picks one to send.

[johnthagen]

For visibility, to others, @ngnpope provided a list of work-arounds for drf-spectacular here:

• Allow globally excluding certain content types tfranzel/drf-spectacular#598 (comment)