7 ms·

Ask HN: REST or RPC?

I know that REST is one of the most misunderstood and abused architectural styles today and most of the population that throws the word around doesn't actually know what they're talking about. I've been trying to wrap my head around actual REST (as in Richardson's Maturity Model Level 3) and trying to contrast it with RPC. So far, I have to admit, it's not doing much for me. It may be that the RPC style of doing things is so engrained in me - but the RPC way just seems more natural and easier to me. I'd be interested to hear from people who've done both RPC (I come from the .NET space, so my flavor of RPC is mostly WCF) and REST - in what situations would you pick REST over RPC?

argonaut 13y ago
It bears noting that when people talk about REST(ful) APIs, they are not actually talking about strictly 100% pure REST. Some parts of the original REST spec are impractical in practice (HATEOAS, anyone?) and are never used.
- dragonwriter 13y ago
  HATEOAS works pretty well for the web, so I don't know that I'd say its never used or impractical. Most people who talk about RESTful API's seem to use it as a term for RPC-over-HTTP without the overhead of SOAP, rather than to meaning anything with even a passing resemblance to what was described in Fielding's thesis.
  - argonaut 13y ago
    It's never used in RESTful APIs, which is what I mean.
    - dragonwriter 13y ago
      Almost none of REST is used in most "RESTful" APIs except incidentally, because "RESTful" APIs are usually simple RPC-over-HTTP, and have nothing to do with REST. OTOH, there are RESTful APIs that actually try to use REST, including HATEOAS, such as PayPal's [1]. [1] https://developer.paypal.com/docs/integration/direct/paypal-rest-payment-hateoas-links/ https://developer.paypal.com/docs/integration/direct/paypal-...
      - aashishkoirala 13y ago
        Thanks for the link to PayPal's API. I would be curious to know if doing pure HATEOAS like that has reaped any specific benefits for them.
rpedela 13y ago
REST is completely fine if you are providing an HTTP interface to a key/value store. If the API performs complex logic then RPC is much better. You will likely rip out all your hair trying to force complex logic into a REST API. SQL is an example of an RPC API that does not fit REST at all. In a single query, you can read and write data or call a custom function which could literally do anything. Except for basic CRUD, it would be nearly impossible to make SQL a REST API. The other thing to keep in mind is that REST has become a marketing term. Business people do not know what REST is, but they do know that if they see it then it is usually a good thing. Don't know if that matters for you.
- aashishkoirala 13y ago
  That is exactly the impression I got, and I guess it is true - it has become a marketing term - and joined the likes of SOA and Agile - yet more in a list of terms people who have no idea what they're talking about like to abuse.
platinumdragon 13y ago
I'm pretty surprised to read such uninformed comments on hacker news, but then I'm relatively new the community. Yes, RPC is better suited for complex abstract actions where you don't have a resource as a context, whereas REST is better suited for resource-based access and actions. Both should have a place in your toolbox, and to say that one is superior to the other is simply trolling for a religious war. REST is not relegated to CRUD, and is being grossly misrepresented when it is said to. SQL is a scripting language, not a RPC or REST API. If you can make SQL into a RPC, I'd love to see it. It must be absolutely nasty. RPC is great for situations where you don't necessarily need an answer, or the answer is so abstract that it doesn't really relate to a specific resource. The great thing about RPC is you usually have something like a WSDL that many tools can use to generate your client code for you. It makes it very easy to implement into your client project, but can be very brittle, as any changes to the WSDL will break the client. REST is great for when your actions revolve around resources, whether they be actions or access. Not everything needs to be relegated to the URL. You can post or put just about anything in the body, including SQL if you were so inclined (please don't ever do something like that). The thing about this is you're using the resource in the URL as context, so it's a different way of modeling your API. Though there is WADL and a couple of other standards for describing a RESTful service, none of them are well accepted and there is poor tool support for generating client code for you. This is a disadvantage in that it forces you to roll your own code (which probably averages about 5 lines per call), but is an advantage in that you can easily follow a "tolerant reader" methodology which makes your client highly resistant to API breakage. If you're smart, you'll use HATEOAS in your responses. It may not be used by all clients, it's up to them, but it does allow flexibility if they do use it. We've had great success with it at the Fortune 100 company I work for. I agree that many people use REST as a marketing term and don't fully understand it. Those who do though are using it successfully and enjoy when the opportunity to use it for their project. The important thing is to remember that both are important and not try to fit one into a hole that calls for the other.

argonaut 13y ago

It bears noting that when people talk about REST(ful) APIs, they are not actually talking about strictly 100% pure REST. Some parts of the original REST spec are impractical in practice (HATEOAS, anyone?) and are never used.

dragonwriter 13y ago
HATEOAS works pretty well for the web, so I don't know that I'd say its never used or impractical. Most people who talk about RESTful API's seem to use it as a term for RPC-over-HTTP without the overhead of SOAP, rather than to meaning anything with even a passing resemblance to what was described in Fielding's thesis.
- argonaut 13y ago
  It's never used in RESTful APIs, which is what I mean.
  - dragonwriter 13y ago
    Almost none of REST is used in most "RESTful" APIs except incidentally, because "RESTful" APIs are usually simple RPC-over-HTTP, and have nothing to do with REST. OTOH, there are RESTful APIs that actually try to use REST, including HATEOAS, such as PayPal's [1]. [1] https://developer.paypal.com/docs/integration/direct/paypal-rest-payment-hateoas-links/ https://developer.paypal.com/docs/integration/direct/paypal-...
    - aashishkoirala 13y ago
      Thanks for the link to PayPal's API. I would be curious to know if doing pure HATEOAS like that has reaped any specific benefits for them.

rpedela 13y ago

REST is completely fine if you are providing an HTTP interface to a key/value store. If the API performs complex logic then RPC is much better. You will likely rip out all your hair trying to force complex logic into a REST API. SQL is an example of an RPC API that does not fit REST at all. In a single query, you can read and write data or call a custom function which could literally do anything. Except for basic CRUD, it would be nearly impossible to make SQL a REST API. The other thing to keep in mind is that REST has become a marketing term. Business people do not know what REST is, but they do know that if they see it then it is usually a good thing. Don't know if that matters for you.

aashishkoirala 13y ago
That is exactly the impression I got, and I guess it is true - it has become a marketing term - and joined the likes of SOA and Agile - yet more in a list of terms people who have no idea what they're talking about like to abuse.

platinumdragon 13y ago

I'm pretty surprised to read such uninformed comments on hacker news, but then I'm relatively new the community. Yes, RPC is better suited for complex abstract actions where you don't have a resource as a context, whereas REST is better suited for resource-based access and actions. Both should have a place in your toolbox, and to say that one is superior to the other is simply trolling for a religious war. REST is not relegated to CRUD, and is being grossly misrepresented when it is said to. SQL is a scripting language, not a RPC or REST API. If you can make SQL into a RPC, I'd love to see it. It must be absolutely nasty. RPC is great for situations where you don't necessarily need an answer, or the answer is so abstract that it doesn't really relate to a specific resource. The great thing about RPC is you usually have something like a WSDL that many tools can use to generate your client code for you. It makes it very easy to implement into your client project, but can be very brittle, as any changes to the WSDL will break the client. REST is great for when your actions revolve around resources, whether they be actions or access. Not everything needs to be relegated to the URL. You can post or put just about anything in the body, including SQL if you were so inclined (please don't ever do something like that). The thing about this is you're using the resource in the URL as context, so it's a different way of modeling your API. Though there is WADL and a couple of other standards for describing a RESTful service, none of them are well accepted and there is poor tool support for generating client code for you. This is a disadvantage in that it forces you to roll your own code (which probably averages about 5 lines per call), but is an advantage in that you can easily follow a "tolerant reader" methodology which makes your client highly resistant to API breakage. If you're smart, you'll use HATEOAS in your responses. It may not be used by all clients, it's up to them, but it does allow flexibility if they do use it. We've had great success with it at the Fortune 100 company I work for. I agree that many people use REST as a marketing term and don't fully understand it. Those who do though are using it successfully and enjoy when the opportunity to use it for their project. The important thing is to remember that both are important and not try to fit one into a hole that calls for the other.