Add support for Parameter Serialization

[Floppy012]

[!IMPORTANT] This PR will not be merged because the project is no longer maintained. Check the announcement in the README

Summary

This PR addresses #654 (and probably #917). It adds support for parameter serialization for path-parameters, query-parameters and headers as per https://swagger.io/docs/specification/serialization/.

Details

I've implemented this feature by adding a small data class that gets instantiated for each parameter. The class holds the style and explode values as well as the parameter name and value. I did this to allow backwards compatibility in case someone directly uses the ApiRequestOptions. Same applies to all functions handling the affected parameter types. If the value provided is not an instance of the data class the known behavior will occur.

I also didn't want to be too strict on the rules in regards of discarding parameters or throwing errors. So currently if invalid style/explode values are provided, the parameters will at best be serialized with the default style/explode settings for that parameter type or at worst the data will end up malformed (IMO this is fine as we can't really do anything about an invalid spec file or we would have to perform a validation when parsing the spec file).

As a side effect of adding the parameter serialization for headers, header values can now also be arrays or objects (just as url and query parameters).

Breaking Changes

• Object serialization in query parameters will change
  • According to the OpenAPI specification, objects in query parameters will use form style and are exploded by default. Generated clients before this PR serialize objects with the deepObject style. So ?id[keyA]=valA&id[keyB]=valB will change to ?keyA=valA&keyB=valB when this PR gets merged.

ToDO

• [x] ~~Unit~~ e2e tests for parameter serialization

[PaulVrugt]

@ferdikoomen please look at this, we are waiting for support for explode: false

[PaulVrugt]

does this also include support for explode: false with querystring parameters making it possible to pass: querystringparam=1,2 instead of querystringparam=1&querystringparam=2? This is what we are waiting for

[Floppy012]

does this also include support for explode: false with querystring parameters making it possible to pass: querystringparam=1,2 instead of querystringparam=1&querystringparam=2? This is what we are waiting for

Yes. This PR should implement full support for parameter serialization.

[PaulVrugt]

Alrighty then, let's get this merged and released!

[Floppy012]

Alrighty then, let's get this merged and released!

I don't have the feeling that this is going to happen anytime soon. Last non-automated merge to main was in Oct 22. Since then the author does not have any activity on Github. Meanwhile issues almost get created on a daily basis where people assign Ferdi and tag him.

Let's hope nothing bad happened to him!

We need this feature at my company and our solution to this not being merged was to fork it and merge it there and publish it to an internal registry. It's unnecessarily complex but the only solution atm.

[ferdikoomen]

@Floppy012 @PaulVrugt Sorry for the lack of communication from my side, we are building a house and that takes up most of my time, i recently did stop freelance project work, so hopefully i have some time to revamp this repo and add a "request for maintenance" section here, and invite others to admin/contribute. I will check the open PR's this weekend!

[radusuciu]

This seems to be a great addition that would increase type safety in my project, thanks for working on it!

[elibolonur]

@ferdikoomen this would be a great addition to the generator! Unfortunately the branch has conflicts now @Floppy012 please let me know if I can help!

[Floppy012]

@elibolonur thanks for the reminder. I've rebased and resolved the conflicts.

[BierDav]

@Floppy012 can you please resolve the merge issues and @ferdikoomen can you please than merge this, we need this 😊

[Floppy012]

Rebased and resolved conflicts again. @ferdikoomen I would be really happy if this could get merged soon.

[BierDav]

@ferdikoomen ?

[elibolonur]

@ferdikoomen please :) this feature would be a huge improvement to my codebase as well 🙏

[mrlubos]

Hey all, this feature will be available over at https://github.com/hey-api/openapi-ts 🚀