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

21–30 of 124 posts

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

#21

Post by smacktoward »

mpdehaan2 wrote: post #5

I started developing network apps before REST existed -- probably like many people here, that wasn't long ago, SOAP, various things like RMI and then XMLRPC were things. SOAP was never good anyway, deeply buried in standards committee goo. But there are still things I miss from these things. When I found XMLRPC after doing all these things, it was very much a "WOW" moment. (JSON of course, with it's definite differen…

> SOAP was never good anyway, deeply buried in standards committee goo.

IMO SOAP in its very early days was actually fairly pleasant, at least when compared to the existing alternatives (things like COM and CORBA, which, ew). XML-RPC was also nice, in a "keep it simple, stupid" kind of way.

Then of course SOAP crushed XML-RPC, the crew of the USS Enterprise got their hands on it, and the rest is (depressing) history.

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

#22

Post by xrstf »

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 just don't fit the resource-driven model well. But for example, for performing logins (something which I previously did via "POST /login"), I switched to doing a "POST /sessions", because that's what a login it is: adding a new session.]

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

#23

Post by RangerScience »

Hmm. Seems to me that this actually relates well to the object-oriented versus functional programming "debate" - REST deals with things (like OO), RPC deals with actions (like functional).

But, in my experience, most requests consist of a "thing path" - host, resource; and then some "function" - get, update, other. POST is then the '=' - it's still a function under the hood, but because of it's commonality and interaction with language, the syntax is a little special.

In which case (and this is what I see in the APIs I most like) "the right thing to do" is to combine them, where you have pure REST when you're interacting with the object, but use RPC style when you're interacting with the object's actions.

Let's say I have some machinery exposed through an API, you might do:

GET host.com/machines/1 -> {"machine":"mixer","state":"off"} POST host.com/machines/1?state:on -> 200

because I'm interacting with its state. But if I need to interact with its functional actions:

POST host.com/machines/1/mix?substance1=h20&substance2=c02

it makes more sense to phrase it as an action. "I want you to start doing this". You could also phrase as a request for a state transition: POST host.com/machines/1?state:mixing&substance1=h20&substance2=c02

but (to me) that seems way weirder, generally.

I've got to go, but I think the answers change you go from physical resources to virtual ones, say, things that process information -

GET host.com/stock_analyzer/6/analyze?ticker=GOOG

where you might control state variables regarding the analysis algorithms using a REST-style.

Thoughts?

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

#24

Post by happyshadows »

bluepnume wrote: post #20

I generally use a pattern like: GET /api/resource POST /api/resource/action Where 'action' is something a bit more descriptive than 'PUT' or 'DELETE' or whatever. Kind of like an object-oriented api... I'm still always dealing with resources, but I have custom actions for specific use cases.

This is my approach as well. Works very well with an event-sourcing model.

It is much easier to capture user intent with POST /api/customer/1/change-address-due-to-move { "address_1": "...", "address_2": "...", ... }

than with: PUT /api/customer/1 { "address_1": "...", "address_2": "...", ... }

Also, GET /api/resource/action is nice place for a payload describing the expected inputs to the action. Link it all together with hypermedia and you really have something ;)

Believe others are coming around to this line of thought: ThoughtWorks included "REST without PUT" onto their technology radar earlier this year.

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

#25

Post by Zikes »

happyshadows wrote: post #24
bluepnume wrote: post #20

I generally use a pattern like: GET /api/resource POST /api/resource/action Where 'action' is something a bit more descriptive than 'PUT' or 'DELETE' or whatever. Kind of like an object-oriented api... I'm still always dealing with resources, but I have custom actions for specific use cases.

This is my approach as well. Works very well with an event-sourcing model. It is much easier to capture user intent with POST /api/customer/1/change-address-due-to-move { "address_1": "...", "address_2": "...", ... } than with: PUT /api/customer/1 { "address_1": "...", "address_2": "...", ... } Also, GET /api/resource/action is nice place for a payload describing the expected inputs to the action. Link it all togethe…

How about

    POST /api/customer/1/address {"address": "..."}

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

#28

Post by Zikes »

colordrops wrote: post #26

This seems to me to be a debate between equally usable technologies. The differences between REST and RPC are slight enough that it won't make a big difference which you go with. To spend too much time on this would be bike shedding.

Tabs vs Spaces

Emacs vs Vim

Destined to become one of the great debates of history.

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

#29

Post by grandalf »

RangerScience wrote: post #23

Hmm. Seems to me that this actually relates well to the object-oriented versus functional programming "debate" - REST deals with things (like OO), RPC deals with actions (like functional). But, in my experience, most requests consist of a "thing path" - host, resource; and then some "function" - get, update, other. POST is then the '=' - it's still a function under the hood, but because of it's commonality and intera…

> REST deals with things (like OO), RPC deals with actions (like functional).

I think it's the opposite: REST deals with data, while RPC calls an operation that has side effects on some (potentially) unknown state.

Not arguing that one is better just offering my thoughts on the analogy.

Post reply on HN