File Upload with multipart/form-data

[MalteBecker]

Hi,
I'm just working with that great client for a short time and now I'm trying to upload a file with multipart/form-data and it will not run.
Does anyone have an example of doing this?

I'm not quite sure if I found a bug or if I'm just too dumb to use the client.

Thanks for your help.

[MalteBecker]

I just found out something what confuses me. In the openapi-python-client/end_to_end_tests/golden-record/my_test_api_client/api/tests/upload_file_tests_upload_post.py you have the line multipart_multipart_data = multipart_data.to_multipart().

If I generate the client from the example openapi.json i get a different result. I get:

files = {}
data = {}
for key, value in multipart_data.to_dict().items():
    if isinstance(value, File):
        files[key] = value
    else:
        data[key] = value

Which is in the same style my code is generated. Do i use a older version? I just installed it with python -m pip install openapi-python-client.

[dbanty]

The main branch in the repo has several improvements that haven't been released yet. 0.10.0 will be coming soon with the multipart changes you've noticed.

[dbanty]

@MalteBecker I've just released 0.10.0, let me know if it solves your issue!

[MalteBecker]

@dbanty thanks for the information. I just started testing it and until now it runs like a charm. Thanks for the update!

[MalteBecker]

@dbanty Sadly I have another problem with the multipart/form-data. This time I am not sure if the client does not work correct or if my server doesn't parse correctly.
Here is a part of my ApiDescription:

openapi: 3.0.3
paths:
 /api/MyApi/v1/Objects:
    post:
      tags:
      - Objects
      operationId: GenerateObject
      requestBody:
        content:
          multipart/form-data:
            schema:
              $ref: '#/components/schemas/CustomObject'
        required: true
      responses:
        202:
          description: Accepted

components:
  schemas:
    CustomObject:
      type: object
      properties:
        File:
          type: string
          format: binary
        location:
          $ref: '#/components/schemas/Vector3'
        saveAsContent:
          type: boolean
          default: true
      required: 
      - saveAsContent
		  
    Vector3:
      type: object
      properties:
        x:
          type: number
          format: float
        y:
          type: number
          format: float
        z:
          type: number
          format: float

The new client-version generates an request call which looks like this:

kwargs = {
    'url': 'http://127.0.0.1:8585/api/MyApi/v1/Objects',
    'headers': {},
    'cookies': {},
    'timeout': 5.0,
    'files': {
        'File': ('Duck.gltf', open('Path\\Duck.gltf', 'rb'), 'application/binary'),
        'location': (None, '{"x": 15, "y": 25, "z": 56}', 'application/json'),
        'saveAsContent': (None, 'False', 'text/plain')
        }
}

'File' and 'saveAsContent' are correct parsed in my server an it worked fine, but the 'location' is set to null.
If the call would look like this it will work as my server expect it:

kwargs = {
    'url': 'http://127.0.0.1:8585/api/MyApi/v1/Objects',
    'headers': {},
    'cookies': {},
    'timeout': 5.0,
    'files': {
        'File': ('Duck.gltf', open('Path\\Duck.gltf', 'rb'), 'application/binary'),
        'location.x': (None, '15', 'text/plain'),
        'location.y': (None, '25', 'text/plain'),
        'location.z': (None, '56', 'text/plain'),
        'saveAsContent': (None, 'False', 'text/plain')
        }
}

At this point I'm not sure if the client call is incorrect or if my server needs a different parsing. I hope you can help me with this.

[dbanty]

I’m actually not sure if it’s a problem with your schema, this generator, or both 😅. In #372 we elected to not add support for multiple form encodings and just assume application/json for now. My guess is that using dot-joined string keys is a different supported encoding in OpenAPI, but your schema doesn’t specify one. As far as I could tell from the OAI 3.0 spec there is no default… but the spec is often ambiguous so it could be that the default is implicit.

Anywho, if you can figure out which encoding method according to OpenAPI does that dot-separated object key syntax I’ll happily add it as our second supported form encoder 😊.