Revert "[+] support integer64 as string option (#355)" - #431
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
This reverts commit c62333b. The original change conflated the guidance for encoding protobuf messages as json objects with generating an OpenAPI v3 spec file. OpenAPI v3 explicitly allows for integer types of int64 (https://swagger.io/docs/specification/data-models/data-types/#numbers). The OpenAPI v3 spec generated by this tool will then usually be fed into language specific generators which will determine how they want to handle each of the types depending on the specific target language.
a123d58 to
4d065e2
Compare
|
I also think that the generated OpenAPI specification should match the types in the proto file as close as possible and should not be language-specific. So for proto type |
|
Is there any update in this bug? |
|
It appears there is a v2 of the protoc-gen-openapi generator which fixes this issue. Perhaps this project is no longer maintained? I'm going to close this as there appears to be no traction on the issue and https://github.com/grpc-ecosystem/grpc-gateway/tree/main/protoc-gen-openapiv2 appears to work correctly. |
For the reasoning outlined in google#431 this adds back in the ability to serialize 64-bit integer types as integer rather than string. However, recognizing that some users will be using this for APIs compatible with proto JSON, this keeps both options in, controlled by a command-line flag.
For the reasoning outlined in google#431 this adds back in the ability to serialize 64-bit integer types as integer rather than string. However, recognizing that some users will be using this for APIs compatible with proto JSON, this keeps both options in, controlled by a command-line flag.
For the reasoning outlined in google#431 this adds back in the ability to serialize 64-bit integer types as integer rather than string. However, recognizing that some users will be using this for APIs compatible with proto JSON, this keeps both options in, controlled by a command-line flag.
ref: #355
closes: #411
This reverts commit c62333b.
The original change conflated generating an OpenAPI v3 spec file with the guidance for encoding protobuf messages as json objects. OpenAPI v3 explicitly allows for integer types of int64 (https://swagger.io/docs/specification/data-models/data-types/#numbers). The OpenAPI v3 spec generated by this tool will then usually be fed into language specific generators which will determine how they want to handle each of the types depending on the specific target language.