Render fields of a object when using MultipartFormField

[MarcusDunn]

Currently MultipartFormField.string().json() renders in the openapi spec as a type: string without any further context (even if you map the JsonObject). mapWithNewMeta + ParamMeta.Object renders it as an object, but again with no information about the shape of the object.

I would like to be able to map a MultipartFormField and render the object in the schema with all of it's feilds. This is supported by the openapi spec and they even declare the default content type for these multipart object fields is application/json.

I would like this as I transfer a lot of files (and cannot take the base64 overhead and use json) as well as use codegen to generate a client to consume my API.

I would be more than happy to implement this myself. I would like to know if it's feasible and if so - some pointers on where to begin.

[daviddenton]

There are 2 bits to this - I've done the first on a branch (rendering_json_form_fields_as_objects). I have implemented your method of:

val a = MultipartFormField.string().mapWithNewMeta({ it }, { it }, ParamMeta.ObjectParam).required("foo")
// as...
val b = MultipartFormField.json().required("foo") // for nodes - implemented as an extension function imported from Json
val c = MultipartFormField.auto<MyDataClass>().required("foo") // for auto marshalled objects - implemented as an extension function imported from AutoMarshalling

That gets us to your current situation - OA3 rendering appears as an object with no fields, but also adds a nice feature of being able to auto-marshall any String lens directly into a supported object - this can be: Query/Header/FormField/MPFF/EnvironmentKey.

For the next bit - which might be a bit more tricky... making the OA3 renderer output the schema. Note it doesn't have the overall reflective object to use (because it loses the type when it marshalls into a string). But you could potentially get the same output as a JSON object schema without any optional fields (because as far as the renderer is concerned it does not know the optionality).

For the moment, I've also made changes to introduce coerceForSimpleType which converts the object to string in the "type" field for complex objects - this might not be correct, but I'm not currently sure if it's better to have an empty object or a string in the schema definition - at least until we fix this issue or decide on leaving it in a particular state to release.

Feel free to have a play with this on the branch. Would be interested to hear your thoughts on the non-optionality. :)

[daviddenton]

I've merged most of this into the master branch - there are no other changes currently - JSON fields are rendered as empty objects in the JSON schema. Still worth looking at if we can extend it to covert the actual schema.

[daviddenton]

I've released this, but there are problems with adding extension functions to Companion objects which are not found on the classpath (in this case from http4k-multipart) - which are throwing up problems in JUnit, so have reverted it in 4.34.0.1. We will need to take another approach I think unless we can work around.

Caused by: java.lang.NoClassDefFoundError: org/http4k/lens/MultipartFormField$Companion

[MarcusDunn]

Could we use examples in the returning value of a meta block to access the fields?

[daviddenton]

I've made a couple of changes to get nearer towards supporting this, but webform fields still don't have schemas yet. We should be able to get some JsonSchema there, but will not be able to get the automarshalling support of objects - , because the objects aren't available to MultipartFormBody or MultipartForm - it's just the list of fields (MultipartFormField) and files (MultipartFormFile) - the lenses sit on top of these objects.

The kind of schema that we will be able to achieve eventually is the same that is output by the non-auto JSON implementations - ie. the things same format that comes out of JsonToJsonSchema, which works on the Json NODE object models.