support POST form data instead of always json

[drising-mfp]

I am thinking of submitting a Pull Request to add support for POSTing form data (I have a few endpoints that require form data rather than json as input). I have a very naïve version working but honestly it's not very satisfying. So, assuming this might be a well-received feature I have a couple of design options:

• add a withFormData method to the existing HttpRequest

The downside to this is that it would be possible to define both a body and formdata separately and we'd have to error out if we found this to be the case.

• allow for non-json payloads

Right now there's a lot of machinery that assumes the http entity will always be json (or something that can be serialized to json) so this would take a lot more work. It would however, have the advantage of an unambiguous definition of what should go into the request's entity.

• Take an educated guess at request-building time based on the currently available data

Meh. This is not a great idea since it would be too easy to get wrong and would prevent users from having precise control over how the HttpRequest is ultimately represented.

Thoughts?

[agourlay]

Hi @drising-mfp

thank you for sharing your thoughts regarding this limitation of cornichon!

As you have seen it yourself, the library was designed to handle only JSON payload. Although I personnaly do not have a use case for the form-data data type, I am open to to have it supported.

FYI this issue was already raised in the Gitter chat by @kylepotts https://gitter.im/agourlay/cornichon?at=57e92ad676d85b087daa59f3 but seems like he was able to drop the constraint :)

My favorite alternative is obviously the one allowing any non-payload in a generic fashion.

I am afraid there is no clean workaround to do this, the whole chain is expecting JSON.

HttpRequest -> HttpService -> HttpClient

As you noted, allowing any non-json payload to travel through this stack is quite a change, it might be doable to add a new constraint on the body type such that it has a ToEntityMarshaller.

See JSON one definition in the client https://github.com/agourlay/cornichon/blob/master/src/main/scala/com/github/agourlay/cornichon/http/client/AkkaHttpClient.scala#L99

This clearly represents a lot of work, we might be able to find another way.

Maybe you can share what you have done already?

[agourlay]

Decided to work on introducing a generalised solution that handle different kind of DSL input types and HTTP entities.

It will introduce a breaking change for people already using a custom type for the JSON body representation.

[mikhail-g]

Hi @agourlay It would be great to have this feature. Do you plan to implement it in the nearest future?

[agourlay]

Hi @mikhail-g,

I agree with you that it would be great to have this feature 👍

The development is quite expensive because:

• it touches a lot of core internals and early design decisions
• I am not sure how to do it without important breaking changes

One of the strategy I have in mind is to find a use case at my employer to motivate this development during my work time because I do not have enough free time to drive something that big.

TLDR: yes I really want this to happen but unfortunatly no ETA

[agourlay]

Closing due to inactivity.

No work is planned in the foreseeable future to support this feature.