How to encode the policy for translating RPC functions into Interaction Affordances?

[iomz]

Essentially, Protocol Buffers/gRPC and Thing Description/RESTful APIs are two very different interaction patterns. Mapping these two is an interesting problem in order to extend the interoperability among heterogeneous soft/hardware artifacts; however, we have many issues to sort out.

One of them is how to translate one interface to another – in this case, we want to expose the gRPC interface via a TD (unidirectional conversion), but we need to have a policy/rule that maintains the consistency of the translation process, i.e., which RPC function can be mapped to what Interaction Affordance in TD.

We could utilize the naming conventions, Message types, comments, etc. How do we develop this rule? In addition, do we want to embed this rule as a Go code, making them as configurable parameters, or use formal expressions (e.g., yacc) to define such rules?

To give a context, I drew a small sketch – I am now talking about the TD in (ii.). Also what difference is there when comparing other TDs?

[iomz]

This discussion is related to what grpc-gateway does it for us. Although applying the Interaction Affordance concept to RPC functions for higher "semantic interpretability" is a separate topic, perhaps we can utilize their feature to base on.

Also, some logics to convert Messages to DataSchema (a JSON object) can be reused form theirs.

Other must read:

• https://cloud.google.com/blog/products/api-management/understanding-grpc-openapi-and-rest-and-when-to-use-them