4 ms·

Are you really asking why not replace a well-defined RPC protocol that has properly specified data serialization and error signaling with a randomly slapped tog

by dozzie 8y ago

Are you really asking why not replace a well-defined RPC protocol that has properly specified data serialization and error signaling with a randomly slapped together half of an RPC protocol?

jsiepkes 8y ago
This a million times. gRPC / Protobuf allow you to neatly design your messages in a backwards and forewards compatible way. This helps you make changes to your service after your application has been deployed. Why on earth would you try to reinvent something like that?
- RantyDave 8y ago
  Indeed why. Yet we have near-countless 'standardised' ways of marshalling parameters - this is just the one that has the best marketing.
  - gonyea 8y ago
    Driving the highest traffic sites in the world, and the backend systems that power them for 2 decades, is just marketing? Weird.
    - seangrogg 8y ago
      Which company does this? While my workplace has used many of these components individually I can't think of a single team that actually uses gRPC off-the-cuff. Nor can I think of anyone that's even mentioned migrating to it. Disclaimer: I work at Google.
    - exikyut 8y ago
      Well, I'll concede the point, but mass adoption doesn't imply idealness. See also, JavaScript.
techsin101 8y ago
I guess what I am asking is why was it not build on top of websocket instead of http/2
madmax96 8y ago
REST is not intended to be a RPC protocol. Comparing it to one isn't appropriate. The point of REST is to totally and generally describe the semantics of a networked application's state transitions and is protocol-agnostic. GRPC exists to invoke remote functions. Why use REST? That's well-documented in Fielding's thesis [1]. Use the appropriate architecture for the appropriate task. [1]https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding...
- dozzie 8y ago
  > REST is not intended to be a RPC protocol. Comparing it to one isn't appropriate. Ah yes, an obligatory reminder about this cute little original idea that never got implemented for computers to consume. Though whenever somebody talks about REST API, they mean "almost RPC with underspecified semantics", not a hypertext driven way of fetching the data.
  - madmax96 8y ago
    The web, as it is consumed by humans, generally adheres to the RESTful constraints quite well. RESTful architecture (e.g. the architecture that lets you use one client to consume literally billions of applications and provides the mechanisms for you to move between them totally transparently) works very well for building a specific kind of application. Now, most of us are not building the web, and so we have other constraints that are often times more important. You are mistaken in your assertion that this was never implemented, considering the fact you posted this comment from a REST client. A general comparison of REST and RPC is as unproductive and harmful as blindly making "REST APIs" everywhere. The way to escape this game of buzzword bingo is to introduce nuance to our conversations about architectures, not by changing the buzzword.
    - dozzie 8y ago
      >>> REST is not intended to be a RPC protocol. Comparing it to one isn't appropriate. >> Ah yes, an obligatory reminder about this cute little original idea that never got implemented for computers to consume. > The web, as it is consumed by humans, generally adheres to the RESTful constraints quite well. Quite an apt observation: as consumed by humans. But we're comparing something that's commonly called "REST" to an RPC protocol, and RPC protocols are quite clearly intended for computers, not humans. This something that is commonly called "REST", even if you argue it's called incorrectly, is very far from the famous PhD thesis. > You are mistaken in your assertion that this was never implemented, considering the fact you posted this comment from a REST client. OK. If you say that I'm wrong about implementations, show me where's a production system where the computer is the primary consumer (i.e. not merely a terminal for displaying something to a human operator, and not a second-class citizen like web crawling bots) and the system is RESTful in the original meaning. I can't think of even a single one. Note, however, that WWW cannot be considered such an implementation, because its primary consumer is human, not computer, and I remind you once again: we're talking under this post about unsupervised computer-to-computer communication, where human operator is a rare guest. > A general comparison of REST and RPC is as unproductive and harmful as blindly making "REST APIs" everywhere. Much less productive is trying to pull an unrelated idea (the original meaning of "REST") into discussion about machine-to-machine communication, especially that the original term was created post factum to describe WWW's architecture (already existing back then!) and wasn't used for pretty much anything else, so introducing the term hasn't advanced nor produced anything.

by dozzie 8y ago

Are you really asking why not replace a well-defined RPC protocol that has properly specified data serialization and error signaling with a randomly slapped together half of an RPC protocol?

jsiepkes 8y ago

This a million times. gRPC / Protobuf allow you to neatly design your messages in a backwards and forewards compatible way. This helps you make changes to your service after your application has been deployed. Why on earth would you try to reinvent something like that?

RantyDave 8y ago
Indeed why. Yet we have near-countless 'standardised' ways of marshalling parameters - this is just the one that has the best marketing.
- gonyea 8y ago
  Driving the highest traffic sites in the world, and the backend systems that power them for 2 decades, is just marketing? Weird.
  - seangrogg 8y ago
    Which company does this? While my workplace has used many of these components individually I can't think of a single team that actually uses gRPC off-the-cuff. Nor can I think of anyone that's even mentioned migrating to it. Disclaimer: I work at Google.
  - exikyut 8y ago
    Well, I'll concede the point, but mass adoption doesn't imply idealness. See also, JavaScript.

techsin101 8y ago

I guess what I am asking is why was it not build on top of websocket instead of http/2

madmax96 8y ago

REST is not intended to be a RPC protocol. Comparing it to one isn't appropriate. The point of REST is to totally and generally describe the semantics of a networked application's state transitions and is protocol-agnostic. GRPC exists to invoke remote functions. Why use REST? That's well-documented in Fielding's thesis [1]. Use the appropriate architecture for the appropriate task. [1]https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding...

dozzie 8y ago
> REST is not intended to be a RPC protocol. Comparing it to one isn't appropriate. Ah yes, an obligatory reminder about this cute little original idea that never got implemented for computers to consume. Though whenever somebody talks about REST API, they mean "almost RPC with underspecified semantics", not a hypertext driven way of fetching the data.
- madmax96 8y ago
  The web, as it is consumed by humans, generally adheres to the RESTful constraints quite well. RESTful architecture (e.g. the architecture that lets you use one client to consume literally billions of applications and provides the mechanisms for you to move between them totally transparently) works very well for building a specific kind of application. Now, most of us are not building the web, and so we have other constraints that are often times more important. You are mistaken in your assertion that this was never implemented, considering the fact you posted this comment from a REST client. A general comparison of REST and RPC is as unproductive and harmful as blindly making "REST APIs" everywhere. The way to escape this game of buzzword bingo is to introduce nuance to our conversations about architectures, not by changing the buzzword.
  - dozzie 8y ago
    >>> REST is not intended to be a RPC protocol. Comparing it to one isn't appropriate. >> Ah yes, an obligatory reminder about this cute little original idea that never got implemented for computers to consume. > The web, as it is consumed by humans, generally adheres to the RESTful constraints quite well. Quite an apt observation: as consumed by humans. But we're comparing something that's commonly called "REST" to an RPC protocol, and RPC protocols are quite clearly intended for computers, not humans. This something that is commonly called "REST", even if you argue it's called incorrectly, is very far from the famous PhD thesis. > You are mistaken in your assertion that this was never implemented, considering the fact you posted this comment from a REST client. OK. If you say that I'm wrong about implementations, show me where's a production system where the computer is the primary consumer (i.e. not merely a terminal for displaying something to a human operator, and not a second-class citizen like web crawling bots) and the system is RESTful in the original meaning. I can't think of even a single one. Note, however, that WWW cannot be considered such an implementation, because its primary consumer is human, not computer, and I remind you once again: we're talking under this post about unsupervised computer-to-computer communication, where human operator is a rare guest. > A general comparison of REST and RPC is as unproductive and harmful as blindly making "REST APIs" everywhere. Much less productive is trying to pull an unrelated idea (the original meaning of "REST") into discussion about machine-to-machine communication, especially that the original term was created post factum to describe WWW's architecture (already existing back then!) and wasn't used for pretty much anything else, so introducing the term hasn't advanced nor produced anything.