how to implement a repeated request parameter

[sheepdreamofandroids]

I must be missing something completely. My usecase is a simple GET endpoint taking a list of Long ids and returning associated data.
I modelled the input parameter "ids" as

data class ProductImagesRequest(@QueryParam("multiple ids.") val ids:List<Long>)

When calling it with parameters like ?ids=1&ids=2&ids=3 I get this error:

com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot deserialize instance of `java.util.ArrayList<java.lang.Long>` out of VALUE_STRING token

Why would a request parameter be deserialized from xml or json?

I love this library BTW, it's a very elegant solution!

[Wicpar]

Hi,

Thank you for this issue, i know this would happen eventually.
Currently only primitive types are implemented since i use the jackson parser as a quick fix, there are no standard parsers for the query parameter standards as far as i know, and the query parameter standards are quite wonky as well.
Here is the spec:
https://swagger.io/docs/specification/serialization/
Here is the relevant function to change the behavior:
https://github.com/papsign/Ktor-OpenAPI-Generator/blob/master/src/main/kotlin/com/papsign/ktor/openapigen/route/OpenAPIRoute.kt#L74

I am quite busy on another project at the moment, feel free to make a pull request, but once finished i can work on it.

[sheepdreamofandroids]

Laying traps for unsuspecting developers so you can get PR's of them. Genius!

I'm not exactly bristling with free time myself, but let me look at it.

[Wicpar]

Haha.
I found a library that seems to decode RFC 6570 templates
damnhandy/Handy-URI-Templates#54
I'll see if i can implement it rapidly.
I wanted to avoid implementing the entire RFC from scratch, but if a library gets the job done the modifications are a matter of a few hours at most.

[Wicpar]

Good and bad news...
I can't use the library as is, but i can frankenstein in the proper parsing behavior.

[Wicpar]

After all implementing it from scratch seems a lot faster now.
I think i can get it done by 15:00 GMT+2

[sheepdreamofandroids]

Do you intend to let us specify how parameters have to be encoded? Or will you just accept anything the client throws at you?

[Wicpar]

You will have to specify, defaults being according to the openapi spec, but i will try to make it parse anything you throw at it.
Some collisions are possible, they will be caught during startup.

[Wicpar]

I Have finished implementing the primitives:
implementation 'com.github.papsign:Ktor-OpenAPI-Generator:experimental-parameters-a35e1a0143-1'
i will be adding collections and object support very soon

[sheepdreamofandroids]

Wow, you're on fire!

I'll build your branch and see how that works for my usecase. It's really simple, I just need a list of longs, so that shouldn't be a problem. I'll let you know asap.

[Wicpar]

I am working on the lists and arrays, it's a little trickier than primitives.

[sheepdreamofandroids]

Just a brainfart. Shouldn't RFC 6570 be implemented as a format for kotlinx-serialization?

[Wicpar]

nope, ktor doesn't support RFC 6570 parsing, and no library is made to properly parse individual parameters...

[Wicpar]

lists have been added, you can build the latest changes on jitpack

[Wicpar]

objects are next, but i think i will limit the support to data classes in the beginning...
It should not be too complicated to extend afterwards.
Once that is done i'll clean the whole mess.

[Wicpar]

Deep object support has been added. It does not support empty indices for arrays.
Path param objects and form objects are still missing.
Appropriate errors are thrown on startup if anything is not implemented.