Fix swagger-codegen cpprest generator.

[p-groarke]

Bug

Using swagger-codegen, try and generate a cpprest project. Once this issue is fixed, add cpprest generation to your unit tests.

Request

I started fixing the cpprest generator for codegen, but it is clear that ESI has unexpected endpoints which break codegen.

Here are some (general) issues. You can reproduce them (and more) by running codgen master branch (2.4.0) with the cpprest template.

• End points return raw floats instead of floats encapsulated in a json item.
• End points return raw arrays instead of being encapsulated in a json item.
• POST end points with optional body params. (FIXED)

I started a PR to codegen. It might help you when you try and generate a project and the build fails.
swagger-api/swagger-codegen#7571

Response

Many build errors, some are codegen issues.

Expected

Swagger-codegen generates cpprest project and it builds. Whether it runs without errors is another issue for another day, lets get it compiling first :)

[p-groarke]

Relates to #748

I have a commit that fixes a POST request with an optional bodyParam (which doesn't make much sense). By running codegen without that commit, you will be able to identify all POST endpoints with optional payloads.

[a-tal]

I don't see us 'fixing' the first two bullet points

whats the difference between a 'raw array' and a 'json item'?

sounds like a cpp codegen issue

[p-groarke]

So for example, "/characters/{character_id}/cspa/" response 201:

"responses": {
    "201": {
        "description": "Aggregate cost of sending a mail from the source character to the target characters, in ISK",
        "examples": {
            "application/json": 2950.0
        },
        "schema": {
            "type": "number",
            "format": "float",
            "title": "post_characters_character_id_cspa_created",
            "description": "201 created number"
        }

The schema would likely contain an object with a float inside.

I'm not an expert with the swagger api myself, but I believe it is the norm to encapsulate variables in an object. That way you can use reflection on a variable name and/or have "context". Feel free to close this if you disagree.

[a-tal]

yeah, there's nothing in swagger that enforces the convention of always returning an object. there are several endpoints that return a list of integers, list of strings, same with accepting (and yeah, even some that return just an integer or float)

the point of swagger is to have an authoritative source to tell what types you can expect with each response code, so I don't see the point in forcing a convention that might not work in every context (or adding unnecessary overhead).

If it was invalid JSON I could see your point, but as is I'm of the opinion this is a codegen issue.