When openapi not contains format field for integer type, it is generated as Int32 C# equivalent type about refitter HOT 5 OPEN

@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

from refitter.

@all-contributors please add @vinaymadupathi for bugs

from refitter.

@christianhelle

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

from refitter.

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.

from refitter.

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?

from refitter.