Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do you really know why you prefer REST over RPC?

apihandyman.io

Post reply on HN
Print view View original

61–70 of 124 posts

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

#61

Post by andrewstuart2 »

> 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 implementations that never even touch TCP, much less HTTP.

REST is literally just transferring some state via a representation. RPC is literally just calling a procedure remotely.

Also, yes, hatred of expecting different behaviors from different verbs is irrational. Because verbs indicate actions, and different verbs indicate different actions. It works well in written/spoken language, and it works well in REST and HTTP.

[1]https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluati...

[2]https://en.wikipedia.org/wiki/Remote_procedure_call

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

#62

Post by seanp2k2 »

qsymmachus wrote: post #10

One point that didn't get addressed in this article is the use of HTTP status codes to indicate the result of a request. REST encourages proper use of status codes – 404 for a missing resource, 422 for invalid data, 201 for successful resource creation, etc. – further enhancing the predictability of the API. How does RPC handle status codes?

And yet still so many API developers don't get this, or don't know about it, or don't think it's important. Generic API errors are also pretty bad; a ton I've used will just throw a 400 (or 500) with no information on why.

Relevant: http://blogs.mulesoft.org/api-best-practices-response-handli...

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

#63

Post by bradleyankrom »

wampus wrote: post #38

Is it correct to say that POST is not idempotent? Sometimes it is, and sometimes it isn't. Maybe it would be more accurate to say there's no guarantee that it's always idempotent.

POST is used to create resources that don't already have identifiers. So, if you're repeatedly submitting that form, your request is creating distinct resources on the other end. If the resource already exists -- if it has an identifier -- you'd use (an unsafe, but idempotent) PUT to replace it.

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

#64

Post by andrewstuart2 »

NateDad wrote: 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 list of previous reboots. Updating a reboot record might occasionally be necessary as well if an error occurred.

2. Model the state transition as simply another state. "Rebooting," for example, might be a state you can transfer that represents on -> off -> on.

I'll admit they don't roll off the brain as easily as calling the "reboot" procedure, but I also typically find that it brings a good amount of positives as well. For example, the ability to create reboots brings with it the ability to get a record of those reboots pretty trivially (if you're storing requests).

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

#65

Post by coldtea »

xrstf wrote: post #22

One point of doing REST instead of RPC is because you shouldn't re-invent the wheel. HTTP already has verbs and identifiers, so why create another set of verbs (the RPC methods)? REST is embracing HTTP to its fullest, RPC[overHTTP] is "just" taking advantage of HTTP's ubiquity across platforms. [Edit: I don't mind having a few RPC-style endpoints in a REST API. The world's not a perfect square and sometimes things ju…

>One point of doing REST instead of RPC is because you shouldn't re-invent the wheel. HTTP already has verbs and identifiers, so why create another set of verbs (the RPC methods)?

Because HTTP's verbs weren't created with arbitrary operations in mind, but for specific, HTTP-related tasks.

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

#67

Post by Programmatic »

andrewstuart2 wrote: post #64
NateDad wrote: 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…

My first approach for this is to POST to a reboot/ resource which gives you a reboot/123 ID that you can continue to do a GET against to see the status of the reboot (did it start OK? Is the machine back up?).

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

#68

Post by kmtrowbr »

xirdstl wrote: post #3

I prefer to call my APIs RESTish. That way, I can avoid never ending debates about whether some particular feature of my API conforms to REST.

No kidding. The debate here is a pretty funny. Make things as RESTful as you can and, by all means add additional verbs where necessary (cancel, empty, etc). The point is for your API to be easy to understand and to use by making it more like human language.

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

#69

Post by hartror »

oldmanjay wrote: post #41
wise_young_man wrote: post #35

Earlier quoted context omitted.

POST is used to create a resource. PUT is used to update an entire resource. PATCH is to partially update a resource.

Sure, just so long as you realize that is a convention and not a law.

It isn't just a convention, the reasons for doing this are laid out in the HTTP 1.1 spec and assumed by servers, proxies, browsers, clients and developers.

For example if I hand someone an API with a URI that accepts a PUT they know they can safely retry PUTs to that endpoint because the server state will always end up the same.

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

#70

Post by oldmanjay »

hartror wrote: post #69
oldmanjay wrote: post #41

Earlier quoted context omitted.

Sure, just so long as you realize that is a convention and not a law.

It isn't just a convention, the reasons for doing this are laid out in the HTTP 1.1 spec and assumed by servers, proxies, browsers, clients and developers. For example if I hand someone an API with a URI that accepts a PUT they know they can safely retry PUTs to that endpoint because the server state will always end up the same.

there is nothing in the specification of the PUT verb that indicates it is meant only for complete replacement of an existing resource. in fact, the RFC specifically has a section describing the semantics of creation using PUT. therefore, either your stance is trivially falsified, or you were replying to me out of context, which is intellectually dishonest.

https://tools.ietf.org/html/rfc7231#section-4.3.4

Post reply on HN