christianhelle / refitter

A tool for generating Refit interfaces and contracts from OpenAPI specifications
https://refitter.github.io
MIT License
161 stars 36 forks source link

When openapi not contains format field for integer type, it is generated as Int32 C# equivalent type #167

Open vinaymadupathi opened 10 months ago

vinaymadupathi commented 10 months ago

When openapi doesn't specify format for integer type, generated property is of Int32 whereas the value could be in Int64 range, so is it not better to generate property of type Int64 ?

    "prop1": {
      "type": "integer"
    }

Refer Open API specs for Integer (https://swagger.io/docs/specification/data-models/data-types/#numbers)

christianhelle commented 10 months ago

@vinaymadupathi Thanks for taking the time to report this. I'll see what I can do.

I will most likely not just enforce a number or integer default format because that would be a breaking change, but this could be specified as a command line argument instead. I'll look into what would be best

christianhelle commented 10 months ago

@all-contributors please add @vinaymadupathi for bugs

allcontributors[bot] commented 10 months ago

@christianhelle

I've put up a pull request to add @vinaymadupathi! :tada:

kirides commented 10 months ago

I'd argue that just using "type": "integer" is a bad openapi spec and should be fixed to include appropriate "format": "int64" / "decimal" / "int32" etc.

if this comes from an external source, it would be wise to tell the creator of the spec about the flaw in the openapi doc.

christianhelle commented 9 months ago

I'd argue that just using "type": "integer" is a bad openapi spec and should be fixed to include appropriate "format": "int64" / "decimal" / "int32" etc.

I agree this is the correct course of action to take in this situation.

if this comes from an external source, it would be wise to tell the creator of the spec about the flaw in the openapi doc.

I've dealt with quite a lot of these bad OpenAPI specs myself, and when it comes to large corporate vendors, I noticed that informing them that there are errors in the spec doesn't necessarily mean that anything will be done about it. The worst case is that it remains as it is or gets fixed in a future release. You have probably tried this as well @kirides

In these cases, I take a copy of the spec and adjust it locally. At the end of the day, HTTP API's use JSON, and there are only 3 primitive data types in JSON, so regardless of what numeric data type you use in C# it will always come out as a number

I'm guessing that the use case of @vinaymadupathi is to use tooling to skip adjusting the OpenAPI spec locally. Is this correct?