@bcourtine thanks for the PR. I'd a quick look and overall it looks good.

Can you please add samples/client/petstore/rust-reqwest to the following line in pom.xml so that Travis will test the auto-generated code for Rust (reqwest) client?

Shippable failed tests seems unrelated to current PR. It fails in "ElixirPetstoreClientTests" which is not impacted by this branch commits.

Thanks for your prompt answers.

It looks if you're still busy making code changes. Please let me know when you've finished and I'll take a closer look.

You can review it. It works pretty well (I used the reqwest generator with success on several projects).

There are still some bugs, but I can't find an easy way to correct them, and won't have enough time to work on it soon. For now, I correct theses remaining problems post generation when they occur.

FYI, here are the problems I spotted that are not corrected yet:

• If a query parameter has type Vec<i32>, generated code does not compile:

        let query_string = {
            let mut query = ::url::form_urlencoded::Serializer::new(String::new());
            query.append_pair("vec_i32_param", &vec_i32_param.join(",").to_string());
            query.finish()
        };

It must be corrected by something like:

        let query_string = {
            let mut query = ::url::form_urlencoded::Serializer::new(String::new());
            let vec_str_param: Vec<String> = vec_i32_param.iter().map(|p| p.to_string()).collect();
            query.append_pair("vec_i32_param", &vec_str_param.join(",").to_string());
            query.finish()
        };

• Header management has several problems (marked as TODO in RustClientCodegen.java) .

With reqwest, I did not find a simple way to create a custom raw header (like with hyper), and had to introduce a structure for each header (cf. configuration.rs file). All possibles headers are collected in java postProcessOperationsWithModels method. Theses headers are used without transformation. So, corresponding generated code does not respect Rust case convention. Worse, if a header key contains a char like '-', generated code does not compile.

Another thought about headers. In Cargo.toml, for reqwest generation, I would like to remove explicit hyper dependency to rely on transitive dependency management.

I had to reintroduce the dependency because of headers. Implementing reqwest::header::Header requires to use directly hyper::error::Error. It is the only required code where reqwest does not obfuscate hyper usage.

        let vec_str_param: Vec<String> = vec_i32_param.iter().map(|p| p.to_string()).collect();

What about using {{#isInteger}} and/or {{#isLong}} tag to add the above line for integer and/or long?

Are theses booleans valuated for a list of integers/longs?

I prefer waiting for @bjgill opinion:

• This problems is not specific to reqwest and also exists on hyper generated code.
• There can be a better Rust syntax to achieve the same goal.

Feel free to wait for @bjgill option. I was just throwing ideas...

If it's a list, you will need to do the following instead:

{{#isListContainer}}
{{#isInteger}}
...
{{/isInteger}}
{{/isListContainer}}

Please use -DdebugOperations or -DdebugModels to get a full list of mustache tags.

@wing328 Thanks for the ideas: your proposal sounds good. I just want @bjgill opinion on the best Rust syntax to achieve correction (there may be a more effective way than transforming each integer into a string before concatenating…).

I don't think any of the Rust generators handle query parameters very cleanly. For lists, you proposal seems sensible. I wonder whether we want to special-case integers, though. Will we not want to do the same thing for all non-string types?

Indeed, I believe that String::to_string is a no-op. Thus, could you always include .iter().map(|p| p.to_string()).collect() if {{#isListContainer}}?

Sounds a good idea. I do that and let you review the whole PR ;)

Thanks for the complete review. I will correct this. But since I am quite busy, corrections may not be available before some days.

I just looked at reqwest 0.9 release notes and 😭 :

The RequestBuilder has simple methods to set headers using strings, which can work in most places.

Most custom header code added in configuration template can be dropped with this feature.

@bjgill Most of the points you spotted have been corrected. You can review this new version.

I did not correct model problems, because it would be a breaking change in generated API (since models are used by both hyper and reqwest versions), especially replacing accessors by public fields.

Looks good, thanks. I think all my outstanding comments are things that are present in the hyper generator already and therefore should not block this PR.

@bjgill Cool, thanks. I stop changing code for now and it let you (or @wing328 ) merge the PR.

@wing328 Done.

Poke @bjgill who suggested merging theses scripts ;)

I'm happy for this to be merged (modulo CI) - sorry for suggesting something that you then had to undo.

@bjgill I was just trolling. Merging samples scripts (and undoing it) was trivial.

@wing328 - anything else? Otherwise, I'll merge this tomorrow.

@bjgill nothing from me. Please go ahead with the merge.

Thank you @bcourtine again for the contribution and @bjgill for the review.

I've sent out a tweet (https://twitter.com/oas_generator/status/1055863197687664640) to help promote the enhancement.

Have a nice weekend.

@bcourtine thanks for the PR, which is included in the v3.3.2 release: https://twitter.com/oas_generator/status/1057649626101112832