An RPC has free call semantics (hence the name), while REST puts certain boundaries on the meaning of the input messages and the results. Actually, when reading the dissertation, Fielding doesn’t speak about HTTP for a long time.
REST, in his description, is a set of voluntary constraints put on the interaction model, to allow intermediates and the client to better reason about them. The constraints he describes mostly come down to describing exchange of data instead of talking about functionality.
It doesn’t fit everything, e.g. I find REST APIs for most cloud providers incredibly odd, as they rarely deal with recources that fir REST semantics well.
It doesn’t fit everything, e.g. I find REST APIs for most cloud providers incredibly odd, as they rarely deal with recources that fir REST semantics well.
I agree. This is exactly what I think every time I use Google Cloud Compute Engine’s API. I’m wondering why they try so hard to fit in the RESTful style.
A lot of the motivation can be that successive REST requests don’t need to hit the same back-end server as earlier ones. Remember, the ST is “state transfer”, as in each request contains everything that’s needed to proceed.
This is important if you have, say, five hundred copies of your service behind a load balancer, and you don’t want to use sticky sessions because they reduce the efficacy of load balancing.
It doesn’t remove other issues that can limit scalability, such as database contention, but it eliminates one of the big ones.
The problem is that cloud providers have an inherent, non-transferable, visibly evolving state. (e.g. a machine going from starting to booting to started to down) Many of the operations on them aren’t repeatable.
So the returned messages are more handles then anything else, which could be done with RPC as well.
REST fits their diagnostics APIs well, but that’s something else.
It’s very true, the common REST APIs, like the one in the article, are still very much RPC, architecturally speaking. There’s still some benefits over a single-endpoint RPC setup though.
I read the article too and I don’t feel like the author is suggesting such a thing. The article clearly speaks of RPC in the context of HTTP. But I agree this is a very restrictive application of RPC :-)
REST is like functional programming to me. I’ve used it. It has a unique flavor. Never once has it made things easier for me. Computers: still awful.
How is a REST API not an RPC?
An RPC has free call semantics (hence the name), while REST puts certain boundaries on the meaning of the input messages and the results. Actually, when reading the dissertation, Fielding doesn’t speak about HTTP for a long time.
REST, in his description, is a set of voluntary constraints put on the interaction model, to allow intermediates and the client to better reason about them. The constraints he describes mostly come down to describing exchange of data instead of talking about functionality.
It doesn’t fit everything, e.g. I find REST APIs for most cloud providers incredibly odd, as they rarely deal with recources that fir REST semantics well.
I agree. This is exactly what I think every time I use Google Cloud Compute Engine’s API. I’m wondering why they try so hard to fit in the RESTful style.
A lot of the motivation can be that successive REST requests don’t need to hit the same back-end server as earlier ones. Remember, the ST is “state transfer”, as in each request contains everything that’s needed to proceed.
This is important if you have, say, five hundred copies of your service behind a load balancer, and you don’t want to use sticky sessions because they reduce the efficacy of load balancing.
It doesn’t remove other issues that can limit scalability, such as database contention, but it eliminates one of the big ones.
The problem is that cloud providers have an inherent, non-transferable, visibly evolving state. (e.g. a machine going from starting to booting to started to down) Many of the operations on them aren’t repeatable.
So the returned messages are more handles then anything else, which could be done with RPC as well.
REST fits their diagnostics APIs well, but that’s something else.
I don’t understand. You can load balance a RPC service too, without sticky sessions. People do it all the time.
Examples:
http://www.grpc.io/faq/ (search “load balancing”)
http://static.googleusercontent.com/media/research.google.com/fr//pubs/archive/41344.pdf (“F1 servers are mostly stateless, allowing a client to communicate with a different F1 server for each request.”)
Edited to fix a typo
This is a pretty great TL;DR :)
It’s very true, the common REST APIs, like the one in the article, are still very much RPC, architecturally speaking. There’s still some benefits over a single-endpoint RPC setup though.
If you embrace hypermedia, on the other hand…
Author suggest that RPC is HTTP only, and that had me in a skamille like rage right now.
I read the article too and I don’t feel like the author is suggesting such a thing. The article clearly speaks of RPC in the context of HTTP. But I agree this is a very restrictive application of RPC :-)
I think I failed originally to read the “in this post…”, cause you’re right. The author does say they are using RPC == WYGOPIAO over HTTP.