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

31–40 of 124 posts

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

#31

Post by [deleted] »

Zikes wrote: post #25
happyshadows wrote: post #24

Earlier quoted context omitted.

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": "..."}

[deleted]

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

#32

Post by kevincennis »

In my experience, it's way easier to write client apps against a REST API.

If you look at frameworks like Backbone, you can basically create models/collections for a simple CRUD app just by adding some values to a declarative hash (URI, primary key, etc.). Because everything is so predictable, it's really easy to specify a default behavior.

Granted, you could certainly do something similar with an RPC API, but I still think it would likely be harder to generalize.

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

#33

Post by ryan-allen »

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.

Who would have thought that there's more than one way to skin a cat? Or maybe REST is the best chuck out the rest! Pun intended!

I like your approach because it avoids never ending debates.

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

#34

Post by drawkbox »

Many public apis are REST based but do have some RPC actions with url-based HTTP APIs. Sometimes it isn't either or.

For example an API that allows you to get users might also have a job resource or action to perform RPC jobs on the server from a manage api path or similar.

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

#35

Post by wise_young_man »

Zikes wrote: post #25
happyshadows wrote: post #24

Earlier quoted context omitted.

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": "..."}

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

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

#36

Post by delinka »

grandalf wrote: post #29
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.

That looks to me like you both agree. Things==data and actions == "calls an operation"

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

#37

Post by nulltype »

cwbrandsma wrote: post #18

I might be behind on state of the art these days...but my current api has no GET requests, everything is a POST. So in that term, we are not restful. We had a couple of problems with GET requests: all of our data ended up in the url (we have too much info that has to be passed, we stopped working on some browsers), and the data returned could be cached (which is a HUGE problem for us). Now, POSTs can also be cached,…

Yeah, REST is nice for some things, but for normal APIs, you're calling them from a programming language, so calling remote functions (RPC) is very similar conceptually to calling local functions. You might not be able to guess the paths as easily as REST(?) but then again trying to make things REST style doesn't always work out when the things don't allow all the REST verbs or don't fit into a hierarchy, etc.

For serving a filesystem over HTTP REST is great though. And all that caching stuff comes in handy.

From a practical API standpoint though, having two different encodings (GET in url with url parameter encoding, and POST with form encoded or JSON) is a pain and has caused a number of minor bugs and definitely extra work.

Using HTTP is basically a socket for JSON RPC style calls is I think the most straightforward route. In this you have one RPC per request, POST only, with a JSON request body and JSON response. If you use keep-alive it's similar to a socket but can go through some firewalls a bit easier, and has a built-in framing format and metadata thing. Also it works with existing log monitoring tools and frameworks.

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

#39

Post by zzalpha »

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.

I tend to prefer path parameters for actions. Eg:

POST /api/resource;action

As that doesn't pollute the idea that the path itself leads to a resource.

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

#40

Post by nulltype »

xrstf wrote: post #19
cwbrandsma wrote: post #18

I might be behind on state of the art these days...but my current api has no GET requests, everything is a POST. So in that term, we are not restful. We had a couple of problems with GET requests: all of our data ended up in the url (we have too much info that has to be passed, we stopped working on some browsers), and the data returned could be cached (which is a HUGE problem for us). Now, POSTs can also be cached,…

I did the exact same thing in a project of mine. We're shifting away from that and put our data in cookies, so we can cache some of the things our API send out.

You can also use localstorage these days. It's great not having to send data on every request.
Post reply on HN