REST is an architectural style, HTTP is a protocol that implements that style. People really should read the Fielding thesis to understand what it is, and what it isn't.
The concept of resources maps well to URLs, which name things, ie a URL is a noun not a verb. The REST style is about two endpoints transferring their current state of a resource, using a chosen representation, whether JSON, XML, JPG, HTML etc.
gRPC is a remote procedure protocol that uses protobufs as a TLV binary encoding for serializing marshalled arguments and responses. It requires clients and servers to have compiled stubs created to implement the two endpoints. Like most RPC, it is brittle and its abstraction as a procedure call leaks when networks fail.
GraphQL is a query protocol for retrieving things, often with associated (ie foreign key) relations. The primary use is defined in the "QL" of the name.
The benefit of HTTP and the use of limited verbs and expressive nouns (via URLs) is that HTTP defines the operation, expected idempotency, and expected resource "state" after an HTTP request/response has occurred. It has explicit constructs for caching, allowing middleware to optimize responses.
There's nothing in HTTP that requires JSON, the choice of media type is negotiable between the client and server. The same server URL can serve JSON, XML, protobufs, or any other format.
gRPC is yet another attempt to extend the function call of imperative languages to the network. It is the latest in a long line of attempts, Java had RMI, there was SOAP and XML-RPC. Before that there was CORBA and before that there was ONC-RPC. They all suffer from the lack of discoverability, the tight binding to language implementations, and the limitations of the imperative languages that they are written in.
They all end up failing because of the brittle relationship between client and server, the underlying encoding (XDR, IDL, Java etc etc) of the marshalling of arguments and responses is essentially irrelevant.
I agree with all of that, except that procedure calls over a network have "failed". The funny thing is, the way REST is used at 99% of places is just... RPC. People do everything as a POST request (because they're afraid of something being cached), or they may use GET for some things out of a misguided concession to REST, so the verbs really end up having little to do with the actual API semantics, they're just an implementation detail. HTTP may be idempotent, but it's up to the programmers to carry that ideal forward into their implementation. No one is doing programmatic (or even development-time) API discovery, so that aspect of REST goes to waste, also.
The first thing everybody using "REST" should do is completely ignore Fielding's thesis. So much internet comment time is wasted on interpreting that document. It's overly confusing.
I'm fine with the idea that URIs reference resources and HTTP actions are verbs.
I also take issue with the claim that gRPC and protocol buf is brittle; the protocol was explicitly designed to allow older servers to process messages from newer clients (and vice versa) to the best of their ability. More importantly: there are enormous production servers that see waves of server updates (and their associated clients are also getting updated) sending petabytes to exabytes to each other every day; in that sense, it's clearly not brittle or far more users would have a negative experience.
I just spent several weeks onboarding a new system that is based around REST and JSON schema. JSON schema... like most of the things with JSON and Javascript, feel like they were implemented in a hurry by non-experts who wanted to solve a problem, and made something simple enough that large numbers of users adopted it. Now we're stuck with the "core technology is based on less-than-awesome technology". most folks don't even use schema, and the document databases that receive the JSON blobs just sort of treat them as a dynamically created schema defined by the envelope of all extant messages (see, for example, dynamic mapping in elasticsearch).
(my experience includes: XDR and SunRPC, CORBA, protocol bufs, stubby/grpc, XML, WSDL, SOAP, and many more systems. I am not authoritative, and I have my own strong opinions based on experience. But I have to say, I'd rather work in an grpc/protobuf world than a REST/JSON one. It's much more robust.
In what way is REST more discoverable than RPC alternatives? SOAP had WSDL; you could just hit an endpoint and download the whole schema for a web service. With most RPC protocols there's some sort of formal published IDL. That all sounds a lot more discoverable than anything in the REST world, which is pretty much "go read the docs".
How are you using this web site? The entire thing is "discoverable".
What you're talking about is how can you publish a machine readable discoverable API. Just like RPC, there is no "well known" endpoint for getting the API specification.
The RPC IDL is effectively the same as "go read the docs". How is downloading a "formal published IDL" any different to a "formal published OpenAPI specification"?
gRPC just has an entire infrastructure of compilers, parsers and language libraries that generate stub code that you then have to go and "fill in".
OpenAPI is a pretty good standard for defining an HTTP based REST API.
For gRPC, the protobuf is the API specification, a service definition with endpoints, what requests to those endpoints should look like and what responses look like. Of course, there are better and worse implementations, e.g. a well commented proto definition explaining what various args do, etc.
In gRPC the definition is a requirement to use, so at the bare minimum you have the typed structure of requests and responses. There is no such requirement for REST
gRPC has well-known services ServerReflection and ProtoDescriptorDatabase that allow clients to discover all available services, create request bodies, and parse response bodies, without having built-in protocol definitions. It is more discoverable than vanilla REST.
> gRPC is yet another attempt to extend the function call of imperative languages to the network.
Not really. Grpc is just sending/receiving messages to/from an address. Other protocols like COM/CORBA tied the address to an object.
Also there is nothing to prevent you from writing a grpc service in a resource/entity oriented style while REST makes expressing non-resources like actions seem a bit awkward.
The concept of resources maps well to URLs, which name things, ie a URL is a noun not a verb. The REST style is about two endpoints transferring their current state of a resource, using a chosen representation, whether JSON, XML, JPG, HTML etc.
gRPC is a remote procedure protocol that uses protobufs as a TLV binary encoding for serializing marshalled arguments and responses. It requires clients and servers to have compiled stubs created to implement the two endpoints. Like most RPC, it is brittle and its abstraction as a procedure call leaks when networks fail.
GraphQL is a query protocol for retrieving things, often with associated (ie foreign key) relations. The primary use is defined in the "QL" of the name.
The benefit of HTTP and the use of limited verbs and expressive nouns (via URLs) is that HTTP defines the operation, expected idempotency, and expected resource "state" after an HTTP request/response has occurred. It has explicit constructs for caching, allowing middleware to optimize responses.
There's nothing in HTTP that requires JSON, the choice of media type is negotiable between the client and server. The same server URL can serve JSON, XML, protobufs, or any other format.
gRPC is yet another attempt to extend the function call of imperative languages to the network. It is the latest in a long line of attempts, Java had RMI, there was SOAP and XML-RPC. Before that there was CORBA and before that there was ONC-RPC. They all suffer from the lack of discoverability, the tight binding to language implementations, and the limitations of the imperative languages that they are written in.
They all end up failing because of the brittle relationship between client and server, the underlying encoding (XDR, IDL, Java etc etc) of the marshalling of arguments and responses is essentially irrelevant.