CODEWITHSUNDEEP
restprotocol-buffersgrpcapi-design
Leonel Franchelli
Leonel Franchelli

Reputation: 56

GRPC design of a current REST API

I'm looking at the posibility of porting a lot of our REST API services to a gRPC schema, but here is the thing.

We currently make heavy use of one method of the API, that makes calls to multiple PostgreSQL functions based on the name of the function received as a parameter and the input as the body of the request, ie: api.com/functions/exec/{name}, the functions defined in the DB recieves and returns JSON.

So, if I understood well, a gRPC method can only have a static data structure both for receiving and returning types. How can i make it flexible?, because depends on the DB function to be called the data structure to be returned and sent as input

The structure returned by the API is something like

{
  "code": 200,
  "data": {
    "some": "value"
  },
  "status": "Correct..blabla"
}

The structure of the data sent to the API depends on the mode to be used if it's encrypted the request body will be a binary string

a37163b25ed49d6f04249681b9145f63f64d84a486e234fa397f134f8b25fd62f1e755e40c09da09f9900beea4b51fc638e7db8730945bd319600943e01d10f2512fa6ab335fb65de32fc2ee0a2150f7987ae0999ea5d8d09e1125c533e7803ba9118ee5aff124282149792a33dce992385969b9df2417613cd2b039bf6056998469dfb015eade9585cb160275ec83de06d027180818652c60c09ada1c98d6e9ed11df9da737408e14161ae00aaf9d4568a015dc6b6d267f1ee04638dd60e4007dc543524b83ca6b2752c5f21e9dfff3b15e6e55db8b9be9e8c07d64ccd1b3d44ce48cc3e49daee5ae1da5186d9ef6994ccf41dc86a4e289fdbab8ca4a397f929445c42f40268ebb2c3d8bcb80f9e844dba55020da665bce887bd237ae2699876e12cc0043b91578f9df2d76391d50fbf8d19b6969

if it's not encrypted then it's just common JSON

{
  "one": "parameter"
}

One possible solution that I can think of, is to use always a type byte, both on the request and the response types, the only thing that I have to do is convert JSON to a binary string and vice-versa right?

I'm open to suggestions.

Upvotes: 0

Views: 262

Answers (1)

Mehrdad Afshari
Mehrdad Afshari

Reputation: 421988

Depending on your needs and performance requirements, going the raw bytes route might be sensible, if you really don't have any other uses for protobuf fields. If you do, you might want to define a message type that supports encrypted and unencrypted message fields like: https://github.com/grpc/grpc/blob/master/src/proto/grpc/reflection/v1alpha/reflection.proto#L77

Upvotes: 1

Related Questions