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

111–120 of 124 posts

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

#111

Post by guelo »

jbergens wrote: post #97
guelo wrote: post #82

Earlier quoted context omitted.

Let's say you have to integrate with my API that uses GET /user?id=1 instead of /user/1 , How have I made your life worse? Is it going to cost you any extra time at all to code it up?

People usually miss the references that should be encoded within REST responses, The hypermedia part. You should be able to call /user/ and get a list of users whith links to the specific users. This link will be in the correct http-format which means you can discover the api from one or a few starting points. This gets even more obvious when you try to fetch a sub-resource or call a "method" on a resource. Those lin…

I guess what I object to is this concept of discoverability. No matter what, you need documentation to discover these initial endpoints, so why not document the whole API? SOAP had mechanical discover ability with WSDLs but it didn't really work. The reason REST won was because it was simple for humans to understand, which means mostly that the documentation is simple to read. As long as the URLs follow some simple consistent pattern that developers can implement without convoluted effort it should be fine, no need to follow some rigid philosophy. If the documentation is missing some key actions I doubt most developers are going to go poking around hoping to discover undocumented endpoints, they'll probably end up contacting the developer to tell them they're API is broken.

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

#112

Post by joshguthrie »

I prefer REST because one way fits all usages:

GET /resources, POST /resources, GET /resources/id, PUT /resources/id, DELETE /resources/id

Five routes for one resource type. If you need more resources, you nest your URIs. Why would you need POST /deleteResource?idRes=id when you can just DELETE /resources/id?

Code reuse wins.

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

#113

Post by tete »

avodonosov wrote: post #84

REST as "representational state transfer" is a boolshit. The real reason it is popular - it allows to communicate via HTTP, just URLs everyone understands and many tools available, even web browser can be used. If you remember SOAP - the crazy approach to web services promoted before REST, you understand the difference REST made. The same way AJAX is not about XML, REST for me is not about "representational state tra…

> The point of using different HTTP verbs - chaching. Don't do > GET /deleteItem?itemId=456

Yes and no. Use DELETE for delete basically for that reason, but the statement that there are different verbs for caching is wrong. That's what a variety of Headers are there for. The fact that GET is in many cases cached simply is that a GET isn't there for state changes, so it doesn't matter whether it reaches the server (headers are there to tell whether it should).

That's for how things are meant to be, but I agree that it often isn't like that. Properties of HTTP were (ab)used for other things. I think that's a mixture of not understanding HTTP (in other words, not having read RFCs) and of course practical reasons.

We can see that a lot in the web in general. A lot of things get used in different, often completely wrong (as in standards breaking ways) and so things are not really coherent. That includes HTTP, HTML, CSS, ... and that's why new versions of these standards and up having a rather strong break. Caching is actually a great example if you look at HTTP/1 vs HTTP/2. But you may also be look at tags like or in HTML. They started out for styling, then they were discouraged and now they have a more semantic reasoning (see HTML 5's definition).

Doesn't mean that how it is used a lot is exactly bad. It actually just shows that the original ideas, the REST dogmas, etc. maybe don't fit and people use the best from RPC and REST. HTTP is used really universally, which also explains why there are things like WebSockets which barely fit with the original ideas and concepts of what HTTP is. On the other hand it worked extremely well, when you look at its popularity.

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

#114

Post by augustl »

andrewstuart2 wrote: post #61

> 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…

Can confirm, anecdotally. I've used REST over ZeroMQ REQ/REP sockets, for example.

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

#115

Post by augustl »

joshguthrie wrote: post #112

I prefer REST because one way fits all usages: GET /resources, POST /resources, GET /resources/id, PUT /resources/id, DELETE /resources/id Five routes for one resource type. If you need more resources, you nest your URIs. Why would you need POST /deleteResource?idRes=id when you can just DELETE /resources/id? Code reuse wins.

IMO the biggest challenge here is cases that doesn't fit in. What if you want to create or update multiple records in a single operation, for example. There are ways, namely additional batch resources, but structuring that is your problem.

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

#116

Post by pjungwir »

seanp2k2 wrote: post #74
pjungwir wrote: post #16

I really like REST most of the time, but I do have some complaints about Rails' implementation of it. I wrote about them a few years ago: http://illuminatedcomputing.com/posts/2011/07/restless-doubt... Basically, after form submit errors your location bar still says /widgets or /widgets/1 rather than /widgets/new or /widgets/1/edit, so bookmarking that page, or "like"ing it, or Ctrl-L + ing are all broken. I'd much p…

Not sure if I 100% understand, but it sounds like maybe you want to rescue the exceptions you can think of explicitly, then redirect_to previous_thing and return

Exactly. Something like this:

    if @foo.save
      flash[:success] = "Saved"
      redirect_to foos_path
    else
      redirect_to new_foo_path
    end
The standard pattern is to `render 'new'` rather than doing the latter redirect. So I'm complaining that my preferred way isn't "blessed" by the Rails community. Also you need a trick to keep @foo.errors in between requests and load it up in your #new method the second time around.

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

#117

Post by sopooneo »

dkersten wrote: post #109
leeoniya wrote: post #75

Earlier quoted context omitted.

the problem with HTTP REST verbs is that not everything can be (or should be) represented as a resource. a simple example is a one-click payment + order action. you're creating multiple records in different tables - payment gateway transaction log, payment table, an order table, probably creating a customer record, sending email notification, logging a conversion, etc. that sequence of actions does not adhere neatly…

a simple example is a one-click payment + order action A user action doesn't have to correspond to a single API call. Your users single click could translate to multiple API calls. Additionally, as others have already mentioned, a conceptual resource does not have to equal a database entry. In an application (front and back end) there are probably three data models: whats in the database, the "resources" transferred…

Using REST over HTTP certainly gets us a lot for free. But I think we must concede that some APIs somewhere, are not best represented as a small, fixed set of actions on "resources". So then the question becomes, for web APIs, when do the benefits of complying with REST principals get outweighed by the benefits of not?

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

#118

Post by leeoniya »

hartror wrote: post #103
leeoniya wrote: post #80

Earlier quoted context omitted.

how would you differentiate a direct CRUD route with one that performs a lot of additional things? PATCH /orders/123 shipped=1 what does this do? does it simply set a field or does it trigger a shipOrder() sequence that also sets that field? what if you need the ability to do both (eg: admin interface & customer frontend)? I understand that in this case you can instead do something like: POST /shipments order=123 but…

I think some these statements aren't right: > the response to a POST is supposed to be a Location header of the created record The HTTP spec says otherwise: The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describe…

thanks for the corrections.

but here is a perfect example of multiple ways to do the same thing. and the custom additions to HTTP REST begin: multiple locations in the body of the response. the fact that sometimes the headers are sufficient, but at other times, you have to just create your own API to fill in the missing functionality using the response bodies.

no me gusta.

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

#119

Post by dkersten »

sopooneo wrote: post #117
dkersten wrote: post #109

Earlier quoted context omitted.

a simple example is a one-click payment + order action A user action doesn't have to correspond to a single API call. Your users single click could translate to multiple API calls. Additionally, as others have already mentioned, a conceptual resource does not have to equal a database entry. In an application (front and back end) there are probably three data models: whats in the database, the "resources" transferred…

Using REST over HTTP certainly gets us a lot for free. But I think we must concede that some APIs somewhere, are not best represented as a small, fixed set of actions on "resources". So then the question becomes, for web APIs, when do the benefits of complying with REST principals get outweighed by the benefits of not?

I'm not arguing the merits or demerits of REST - just stating that the use case leeoniya outlined can be handled with REST, if you should wish to do so.

It would be silly to say that no API ever is not better represented as something else - for example, a bidirectional streaming API (running over, say, WebSockets?) is probably not a great fit for REST, but for request/response-based API's I do find that so far REST is really nice.

Some people say that actions or commands aren't nicely represented as resources, but personally I like the idea of POSTing to a command resource in order to tell the server to execute a command (and GET could be used to retrieve all outstanding commands, PUT to replace one, DELETE to cancel etc). Again, not requiring a 1:1 match between resource and database makes this possible.

However, even within the world of REST, people have different approaches, so at the end of the day, to each his own. Use what you feel is simplest and makes most sense.

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

#120

Post by jasoncrawford »

hartror wrote: post #99
jasoncrawford wrote: post #72

The Richardson Maturity Model, as explained by Martin Fowler, is the only explanation of the benefits of REST that has ever made sense to me: http://martinfowler.com/articles/richardsonMaturityModel.htm... And for what it's worth, I've only found value in levels 1 and 2, not level 3. Also, this talk by DHH helped me understand how to organize an API by creating more nouns with a restricted set of verbs, instead of pr…

Why do you not find value in hypermedia? Do you have tightly coupled servers and clients?

Yeah. Are there any examples of a generic client that doesn't know what data or API to expect? I don't know of any.
Post reply on HN