Can REST applied using grpc?

Question

As much as REST and HTTP1.1 go hand in hand, technically REST is independent of HTTP (and its GET, POST, PUT... methods).

So I think it is possible to apply REST architectural style/constraints using GRPC.

I think a lot of the "GRPC vs REST" comparisons I've seen are wrong in this regard.

Is there a REST architectural style constraint that we cannot apply using GRPC?

Answer 1

REST stands for "Representational State Transfer", while gRPC stands for "gRPC Remote Procedure Calls" (yes, it's a recursive acronym).

From the name alone, you can see that those are not meant to do the same thing:

• REST is meant to transfer state (POST the state of a new resource, GET to fetch the state, ...)
• gRPC is meant to send commands (or, as it were, calling procedures)

You can absolutely build a set of procedures in gRPC to fetch and update the state of resources, but it would be difficult to call that REST

Answer 2

Is there a REST architectural style constraint that we cannot apply using GRPC?

My primary concern would be the uniform interface constraint:

REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.

(emphasis added).

On the web, we have application/html, a general purpose media type that can express links and forms that "everybody" understands the same way (and one that supports the optional code-on-demand constraint).

For gRPC, this interface constraint is satisfied by ...?

---

It may help to review this comment in Fielding's dissertation:

The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.