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

101–110 of 124 posts

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

#101

Post by avodonosov »

hessenwolf wrote: post #87
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…

Feel free to expand those explanations... :)

Not much to add.

The REST culture gives us some regularity. If we read github API, or google API or facebook API, we know what to expect - that they will use GET to retrieve an object, DELETE to delete an object and so on. It's good there is a convention helping to study new things.

Another good property of REST culture - it prevents people from building thick layers on top of HTTP. While not everything can fit into HTTP (at least error reporting, in my opinion; HTTP error codes are not enough), this culture helps to keep APIs simple.

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

#102

Post by pjc50 »

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…

This is the real advantage of REST - managing state transitions in any distributed system is hard, it's just that REST encourages you to think about it upfront a bit.

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

#103

Post by hartror »

leeoniya wrote: post #80
pekk wrote: post #77

Earlier quoted context omitted.

"Buy this" might create multiple records in different tables, but there is no requirement that one URL in a REST API corresponds directly to one record or one table. The REST API does not have to expose the entire sequence of under-the-hood actions. This does not somehow require RPC to address.

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
   describes the result.
> You cannot return multiple Locations in a header, for example, when multiple records are created.

Again the HTTP spec allows you to manage this (though not in the header):

   10.2.2 201 Created

   The request has been fulfilled and resulted in a new resource being
   created. The newly created resource can be referenced by the URI(s)
   returned in the entity of the response, with the most specific URI
   for the resource given by a Location header field. The response
   SHOULD include an entity containing a list of resource
   characteristics and location(s) from which the user or user agent can
   choose the one most appropriate.
Source: http://tools.ietf.org/html/rfc2616

edit: was quoting HTTP 1.0 rather than 1.1

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

#104

Post by Nemcue »

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 same way AJAX is not about XML, REST for me is not about "representational state transfer", but just about using URLs to request operations from server."

To be fair, that's kind of like saying AJAX isn't about asynchronous requests.

Fielding doesn't agree with you. But that's your interpretation, and that's fine I guess. The point with Hypermedia APIs however is the "representational state transfer" via defined relationships between the resources.

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

#105

Post by Nemcue »

leeoniya wrote: post #80
pekk wrote: post #77

Earlier quoted context omitted.

"Buy this" might create multiple records in different tables, but there is no requirement that one URL in a REST API corresponds directly to one record or one table. The REST API does not have to expose the entire sequence of under-the-hood actions. This does not somehow require RPC to address.

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…

"HTTP REST's multi-item and hierarchical item management are also very hacked-in and necessarily too chatty. You cannot return multiple Locations in a header, for example, when multiple records are created."

So return the URI of a list of records. Easy.

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

#106

Post by collyw »

avodonosov wrote: post #101
hessenwolf wrote: post #87

Earlier quoted context omitted.

Feel free to expand those explanations... :)

Not much to add. The REST culture gives us some regularity. If we read github API, or google API or facebook API, we know what to expect - that they will use GET to retrieve an object, DELETE to delete an object and so on. It's good there is a convention helping to study new things. Another good property of REST culture - it prevents people from building thick layers on top of HTTP. While not everything can fit into…

Other than the verbs used, there isn't very much regularity. Try plugging a back end REST API into a front end framework. In my experience you always need an extra library.

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

#108

Post by Corrado »

MichaelGG wrote: post #83
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?

Eh, sorta. Send an invalid body, say an unavailable product ID, or an invalid quantity. What error will you return? HTTP codes and REST might make sense for some simple scenarios (like managing files), but it breaks down fast otherwise. Shoehorning everything into the few codes HTTP has seems pointless.

Not using HTTP codes is much, much worse. I've dealt with SOAP/RPC APIs that return nothing but 200, no matter what. The actual status is an english word in the response body (i.e. OK, ERROR, etc.) That is a nightmare to deal with because you have to manually decode each and every request instead of using a library to do the heavy lifting for you.

Sometimes I have questions on which HTTP status code to use, but most of the time its pretty clear. And if you stick to the official codes most client side libraries will just work without any drama at all. As a bonus, all of the intermediate processes (proxies, firewalls, CDNs, etc.) will work as well without any finagling on your part. :)

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

#109

Post by dkersten »

leeoniya wrote: post #75
3pt14159 wrote: post #56

Earlier quoted context omitted.

Why would you do this? It makes no sense. By (mostly) adhering to REST patterns you get so much stuff for free. Other developers can quickly get up to speed quickly. Client libraries are easier to write. Things like Ember Data work out of the box. I agree that every now and then doing a POST to /logout is easier than doing a DELETE /access_token/23, but a consistent API is far more worth it.

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 over the API, and what the client has locally (in memory or disk or both) and these three don't necessarily have a 1:1 mapping. For example, in an application I'm working on, the client stores a transformed denormalised version of the resources that allows easy filtering/searching/sorting in the UI, the API resources are very regular semantic "things" and the database stores them in a way that is easy to index and perform access control checks on.

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

#110

Post by dkersten »

leeoniya wrote: post #75
3pt14159 wrote: post #56

Earlier quoted context omitted.

Why would you do this? It makes no sense. By (mostly) adhering to REST patterns you get so much stuff for free. Other developers can quickly get up to speed quickly. Client libraries are easier to write. Things like Ember Data work out of the box. I agree that every now and then doing a POST to /logout is easier than doing a DELETE /access_token/23, but a consistent API is far more worth it.

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 over the API, and what the client has locally (in memory or disk or both) and these three don't necessarily have a 1:1 mapping. For example, in an application I'm working on, the client stores a transformed denormalised version of the resources that allows easy filtering/searching/sorting in the UI, the API resources are very regular semantic "things" and the database stores them in a way that is easy to index and perform access control checks on.

Post reply on HN