gRPC and Swagger annotation differences
I have a protocol buffer definition, which includes google.protobuf.Timestamp as part of a message. The Timestamp message is pretty simple and has the following definition:
message Timestamp
int64 seconds = 1;
int32 nanos = 2;
So the gRPC payload comes out as a simple tuple of values as expected. However I also wanted to generate some swagger annotations for REST API for the same message, but it seems to convert the Timestamp into an RFC 3339 style string:
"timestamp":
"type": "string",
"format": "date-time",
"title": "timestamp"
I recently started working with protocol buffers and gRPC, so I am not sure if I am missing something here, but it seems to be an inconsistency with grpc-gateway implementation. Why would REST be a different format than the gRPC payload? Or am I missing some way to tell protoc-gen-swagger not to convert the message into a string?
go swagger protocol-buffers grpc-gateway edited Nov 13 '18 at 8:56
Grokify
7,25822337
asked Nov 13 '18 at 8:14
pinkstonepinkstone
348
add a comment |
I have a protocol buffer definition, which includes google.protobuf.Timestamp as part of a message. The Timestamp message is pretty simple and has the following definition:
message Timestamp
int64 seconds = 1;
int32 nanos = 2;
So the gRPC payload comes out as a simple tuple of values as expected. However I also wanted to generate some swagger annotations for REST API for the same message, but it seems to convert the Timestamp into an RFC 3339 style string:
"timestamp":
"type": "string",
"format": "date-time",
"title": "timestamp"
I recently started working with protocol buffers and gRPC, so I am not sure if I am missing something here, but it seems to be an inconsistency with grpc-gateway implementation. Why would REST be a different format than the gRPC payload? Or am I missing some way to tell protoc-gen-swagger not to convert the message into a string?
go swagger protocol-buffers grpc-gateway edited Nov 13 '18 at 8:56
Grokify
7,25822337
asked Nov 13 '18 at 8:14
pinkstonepinkstone
348
add a comment |
I have a protocol buffer definition, which includes google.protobuf.Timestamp as part of a message. The Timestamp message is pretty simple and has the following definition:
message Timestamp
int64 seconds = 1;
int32 nanos = 2;
So the gRPC payload comes out as a simple tuple of values as expected. However I also wanted to generate some swagger annotations for REST API for the same message, but it seems to convert the Timestamp into an RFC 3339 style string:
"timestamp":
"type": "string",
"format": "date-time",
"title": "timestamp"
I recently started working with protocol buffers and gRPC, so I am not sure if I am missing something here, but it seems to be an inconsistency with grpc-gateway implementation. Why would REST be a different format than the gRPC payload? Or am I missing some way to tell protoc-gen-swagger not to convert the message into a string?
go swagger protocol-buffers grpc-gateway edited Nov 13 '18 at 8:56
Grokify
7,25822337
asked Nov 13 '18 at 8:14
pinkstonepinkstone
348
I have a protocol buffer definition, which includes google.protobuf.Timestamp as part of a message. The Timestamp message is pretty simple and has the following definition:
message Timestamp
int64 seconds = 1;
int32 nanos = 2;
So the gRPC payload comes out as a simple tuple of values as expected. However I also wanted to generate some swagger annotations for REST API for the same message, but it seems to convert the Timestamp into an RFC 3339 style string:
"timestamp":
"type": "string",
"format": "date-time",
"title": "timestamp"
I recently started working with protocol buffers and gRPC, so I am not sure if I am missing something here, but it seems to be an inconsistency with grpc-gateway implementation. Why would REST be a different format than the gRPC payload? Or am I missing some way to tell protoc-gen-swagger not to convert the message into a string?
go swagger protocol-buffers grpc-gateway go swagger protocol-buffers grpc-gateway edited Nov 13 '18 at 8:56
Grokify
7,25822337
asked Nov 13 '18 at 8:14
pinkstonepinkstone
348
edited Nov 13 '18 at 8:56
Grokify
7,25822337
asked Nov 13 '18 at 8:14
pinkstonepinkstone
348
edited Nov 13 '18 at 8:56
Grokify
7,25822337
edited Nov 13 '18 at 8:56
Grokify
7,25822337
edited Nov 13 '18 at 8:56
Grokify
7,25822337
7,25822337
asked Nov 13 '18 at 8:14
pinkstonepinkstone
348
asked Nov 13 '18 at 8:14
pinkstonepinkstone
348
asked Nov 13 '18 at 8:14
pinkstonepinkstone
348
348
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
I am not that familiar with protoc-gen-swagger itself, but I believe this is happening because of the json-proto format defined here:
https://developers.google.com/protocol-buffers/docs/proto3#json
It's done this way to make it more "natural" for JSON-based APIs.
I don't know of any way to avoid this except by using your own type to hold the timestamp instead of google.protobuf.Timestamp. However, JSON conversion is expected to work correctly in both directions, so when the JSON is converted back to a proto message by the library, it should not cause any problems.
answered Nov 14 '18 at 19:35
Doug FawleyDoug Fawley
1613
Hey @DougFawley, you are right, that seems to be the way it is. Code in protoc-gen-swagger literally checks for "google.protobuf.Timestamp" type and builds a string. It's great to have a consistent rfc3339-type string, but from the code efficiency point of view, it's a conversion of a string back and forth from secs/nanosecs format. But again, what am I talking about when discussing REST and json payload anyways - everything is a string! our sdk on the other side is C++, so the conversion back is not as straightforward, so I ended up defining my own "Timestamp" message and that helped.
– pinkstone
Nov 19 '18 at 22:32
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53276555%2fgrpc-and-swagger-annotation-differences%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I am not that familiar with protoc-gen-swagger itself, but I believe this is happening because of the json-proto format defined here:
https://developers.google.com/protocol-buffers/docs/proto3#json
It's done this way to make it more "natural" for JSON-based APIs.
I don't know of any way to avoid this except by using your own type to hold the timestamp instead of google.protobuf.Timestamp. However, JSON conversion is expected to work correctly in both directions, so when the JSON is converted back to a proto message by the library, it should not cause any problems.
answered Nov 14 '18 at 19:35
Doug FawleyDoug Fawley
1613
Hey @DougFawley, you are right, that seems to be the way it is. Code in protoc-gen-swagger literally checks for "google.protobuf.Timestamp" type and builds a string. It's great to have a consistent rfc3339-type string, but from the code efficiency point of view, it's a conversion of a string back and forth from secs/nanosecs format. But again, what am I talking about when discussing REST and json payload anyways - everything is a string! our sdk on the other side is C++, so the conversion back is not as straightforward, so I ended up defining my own "Timestamp" message and that helped.
– pinkstone
Nov 19 '18 at 22:32
add a comment |
I am not that familiar with protoc-gen-swagger itself, but I believe this is happening because of the json-proto format defined here:
https://developers.google.com/protocol-buffers/docs/proto3#json
It's done this way to make it more "natural" for JSON-based APIs.
I don't know of any way to avoid this except by using your own type to hold the timestamp instead of google.protobuf.Timestamp. However, JSON conversion is expected to work correctly in both directions, so when the JSON is converted back to a proto message by the library, it should not cause any problems.
answered Nov 14 '18 at 19:35
Doug FawleyDoug Fawley
1613
Hey @DougFawley, you are right, that seems to be the way it is. Code in protoc-gen-swagger literally checks for "google.protobuf.Timestamp" type and builds a string. It's great to have a consistent rfc3339-type string, but from the code efficiency point of view, it's a conversion of a string back and forth from secs/nanosecs format. But again, what am I talking about when discussing REST and json payload anyways - everything is a string! our sdk on the other side is C++, so the conversion back is not as straightforward, so I ended up defining my own "Timestamp" message and that helped.
– pinkstone
Nov 19 '18 at 22:32
add a comment |
I am not that familiar with protoc-gen-swagger itself, but I believe this is happening because of the json-proto format defined here:
https://developers.google.com/protocol-buffers/docs/proto3#json
It's done this way to make it more "natural" for JSON-based APIs.
I don't know of any way to avoid this except by using your own type to hold the timestamp instead of google.protobuf.Timestamp. However, JSON conversion is expected to work correctly in both directions, so when the JSON is converted back to a proto message by the library, it should not cause any problems.
answered Nov 14 '18 at 19:35
Doug FawleyDoug Fawley
1613
I am not that familiar with protoc-gen-swagger itself, but I believe this is happening because of the json-proto format defined here:
https://developers.google.com/protocol-buffers/docs/proto3#json
It's done this way to make it more "natural" for JSON-based APIs.
I don't know of any way to avoid this except by using your own type to hold the timestamp instead of google.protobuf.Timestamp. However, JSON conversion is expected to work correctly in both directions, so when the JSON is converted back to a proto message by the library, it should not cause any problems.
answered Nov 14 '18 at 19:35
Doug FawleyDoug Fawley
1613
answered Nov 14 '18 at 19:35
Doug FawleyDoug Fawley
1613
answered Nov 14 '18 at 19:35
Doug FawleyDoug Fawley
1613
answered Nov 14 '18 at 19:35
Doug FawleyDoug Fawley
1613
1613
Hey @DougFawley, you are right, that seems to be the way it is. Code in protoc-gen-swagger literally checks for "google.protobuf.Timestamp" type and builds a string. It's great to have a consistent rfc3339-type string, but from the code efficiency point of view, it's a conversion of a string back and forth from secs/nanosecs format. But again, what am I talking about when discussing REST and json payload anyways - everything is a string! our sdk on the other side is C++, so the conversion back is not as straightforward, so I ended up defining my own "Timestamp" message and that helped.
– pinkstone
Nov 19 '18 at 22:32
add a comment |
Hey @DougFawley, you are right, that seems to be the way it is. Code in protoc-gen-swagger literally checks for "google.protobuf.Timestamp" type and builds a string. It's great to have a consistent rfc3339-type string, but from the code efficiency point of view, it's a conversion of a string back and forth from secs/nanosecs format. But again, what am I talking about when discussing REST and json payload anyways - everything is a string! our sdk on the other side is C++, so the conversion back is not as straightforward, so I ended up defining my own "Timestamp" message and that helped.
– pinkstone
Nov 19 '18 at 22:32
Hey @DougFawley, you are right, that seems to be the way it is. Code in protoc-gen-swagger literally checks for "google.protobuf.Timestamp" type and builds a string. It's great to have a consistent rfc3339-type string, but from the code efficiency point of view, it's a conversion of a string back and forth from secs/nanosecs format. But again, what am I talking about when discussing REST and json payload anyways - everything is a string! our sdk on the other side is C++, so the conversion back is not as straightforward, so I ended up defining my own "Timestamp" message and that helped.
– pinkstone
Nov 19 '18 at 22:32
Hey @DougFawley, you are right, that seems to be the way it is. Code in protoc-gen-swagger literally checks for "google.protobuf.Timestamp" type and builds a string. It's great to have a consistent rfc3339-type string, but from the code efficiency point of view, it's a conversion of a string back and forth from secs/nanosecs format. But again, what am I talking about when discussing REST and json payload anyways - everything is a string! our sdk on the other side is C++, so the conversion back is not as straightforward, so I ended up defining my own "Timestamp" message and that helped.
– pinkstone
Nov 19 '18 at 22:32
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53276555%2fgrpc-and-swagger-annotation-differences%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
