It is still a bit shocking to see how many people are not getting the distinction between an API and a RESTful service.
They are very different things and they have very different goals. The hint is in: how much do you value the client?
If you have full control over both client/server or if we don't care about any 3rd party developing a client library for your service, then go with something like GraphQL or gRPC or SOAP with a nice, typed spec you can generate your code from and optimize the heck out of the bytes coming through the tubes.
If OTOH you have an interest to create a RESTful service that is discoverable, that doesn't require constant client changes, that offer a wider variety of resource representations, that need to stand the test of time, then use HATEOAS and a RESTful architectural style.
gRPC is yet another ... RPC.
Nothing good or bad about that. Just make sure you understand the consequences.
They are very different things and they have very different goals. The hint is in: how much do you value the client?
If you have full control over both client/server or if we don't care about any 3rd party developing a client library for your service, then go with something like GraphQL or gRPC or SOAP with a nice, typed spec you can generate your code from and optimize the heck out of the bytes coming through the tubes.
If OTOH you have an interest to create a RESTful service that is discoverable, that doesn't require constant client changes, that offer a wider variety of resource representations, that need to stand the test of time, then use HATEOAS and a RESTful architectural style.
gRPC is yet another ... RPC. Nothing good or bad about that. Just make sure you understand the consequences.