Live data from Hacker News

Do you really know why you prefer REST over RPC?

apihandyman.io

121–124 of 124 posts

Re: Do you really know why you prefer REST over RPC?

#121

> Both RPC and REST use HTTP protocol which is a request/response protocol. Neither REST nor RPC is tied to HTTP at all. I think the title alone of section 6.3 of Fielding's dissertation, "REST Applied to HTTP", [1] should be enough to convince anybody that they're completely orthogonal concepts, much less the rest of the actual dissertation. The Wikipedia article for RPC [2] also provides numerous examples of RPC im…

Also, yes, hatred of expecting different behaviors from different verbs is irrational.

To be fair, you've kind of rephrased her point into a strawman that's simply opposed to the abstract concept of verbs.

Most of the time, people understand URLs as a one-to-one mapping - each URL has only one meaning, one website. It's not until you actually start writing code to create or consume an HTTP API that you need to learn the concept of the different verbs. In spoken language you don't become functionally fluent with the language and then some time later have a new concept of verbs introduced. So I can understand why the idea that "actually a URL (the part that everyone sees and knows) can have multiple meanings based on this hidden parameter" can feel wrong.

Re: Do you really know why you prefer REST over RPC?

#122

> Both RPC and REST use HTTP protocol which is a request/response protocol. Neither REST nor RPC is tied to HTTP at all. I think the title alone of section 6.3 of Fielding's dissertation, "REST Applied to HTTP", [1] should be enough to convince anybody that they're completely orthogonal concepts, much less the rest of the actual dissertation. The Wikipedia article for RPC [2] also provides numerous examples of RPC im…

Also, yes, hatred of expecting different behaviors from different verbs is irrational. To be fair, you've kind of rephrased her point into a strawman that's simply opposed to the abstract concept of verbs. Most of the time, people understand URLs as a one-to-one mapping - each URL has only one meaning, one website. It's not until you actually start writing code to create or consume an HTTP API that you need to learn…

In defense of the way I phrased that, here's the direct middle section of his tweet: "... different behaviors based on the verb..."

It's very very deliberately called an HTTP verb, for a reason.

It's not that I expect the average person, or even a new developer, should know that HTTP verbs exist or that URLs and URIs literally locate and identify resources in a uniform way. The part that bothers me is that when you deliberately write a blog about the subject that other developers may see and take as credible, you ought to put more effort into making sure your information is accurate before publishing.

Re: Do you really know why you prefer REST over RPC?

#123
post #53

REST is great for CRUD, and easy from javascript/web pages, but it sucks for non-CRUD actions (like logout a user or reboot a machine), and it is not as friendly as RPC for consuming from client libraries. I have designed both, and I find that the contortions you have to do to make your API RESTful is generally not worth it unless you're almost entirely CRUD and are mainly targeting the browser (and even then, you pr…

I'd say the tricky part is modeling state transitions in REST. Rebooting is a transition between states as is logout. Instead of defaulting to RPC, I like to try a few things: 1. Find some abstract resource that represents. POST to reboots to create a new reboot. In order to faithfully bring the resource into parity with the new state you've requested, the system reboots a machine. A GET to reboots should give you a…

These are exactly the contortions I'm talking about. You're building a whole history of reboots and states and stuff, and I just build an RPC function call named "Reboot" and move on, without cluttering my API with crud (heh) like this.

Re: Do you really know why you prefer REST over RPC?

#124
post #96

Earlier quoted context omitted.

so since the post I replied to said that POST is for create, and PUT is for complete replacement, and you just indicated that PUT can be used in ways that the OP did not, and I objected to the OP's prescriptivism, you agree with me despite your stance of arguing with me about it.

Yes I seem to have misinterpreted your response. Apologies.

No worries! I happen to spend a lot of time designing REST APIs.
Post reply on HN