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

When REST isn't Good Enough

braintreepayments.com

Post reply on HN
Print view View original

81–90 of 94 posts

Re: When REST isn't Good Enough

#81

Post by SilasX »

bct wrote: post #76
SilasX wrote: post #72

Earlier quoted context omitted.

That just shows it's HTTPful, not RESTful. In this case, that protocol involves being told how to construct a URI rather than it being presented from a menu of choices discovered by following URIs in the API. I agree that it's much more convenient to have well-defined fill-in-the-blank. I disagree that it matches the requirements of REST, whose proponents always tell me "If you document the URIs or how to build them,…

> involves being told how to construct a URI The crucial thing that you're missing is that it's being told how to construct that URI in-band . Not in a piece of documentation that has to be hard-coded into the client.

So, once again, it turns out that REST reduces to RPC plus some advisable practices as soon as you point out how the original REST schema is woefully impractical.

Not-REST: You can algorithmically generate requests for the information you want based on documentation.

REST: You can algorithmically generate requests for the information you want based on documentation that's provided in the session. (Oh, and forget all that crap we said about URIs having to be presented to the API consumer as part of session's hyperlink navigation.)

So, now I can turn RPC into REST just by slapping a link to the documentation on every response (and maybe moving verbs to the appropriate HTTP request type, even though that has nothing to do with CRUD[1])? Gee, why didn't you say so?

[1] http://news.ycombinator.com/item?id=4811969

Re: When REST isn't Good Enough

#82

Post by BerislavLopac »

sopooneo wrote: post #78
edanm wrote: post #51

Earlier quoted context omitted.

Is there a good book/resource on learning REST API ideas? I'm looking for a beginner's resource for someone who doesn't really grok the ideas behind REST and the motivation for REST. But also something that gets technical very quickly - I've been programming for long enough that I pick ideas up very quickly.

I'm sort of with you, though I've read quite a bit at this point and interacted with a number of APIs of varying degrees of "RESTfulness". The biggest question I wish the various tutorials would address is: why is REST a good idea? Why is this particular way of doing things better than others? And here's one thing I believe is true, that I have literally never seen in a REST tutorial: sometimes REST is not the best w…

"sometimes REST is not the best way to go. Sometimes an RPC architecture is better."

I think that the full versions of there acronyms make a pretty good job of explaining what is best when.

"REpresentational State Transfer": obviously, it transfers state, i.e. information about a certain resource at a given moment. "Remote Procedure Call": obviously, it calls a procedure, which may involve several state changes and other activities. Of course, a procedure may be masked behind a REST endpoint (e.g. when you POST some data and do some procedure before you end up with a certain state) and vice versa (e.g. a simple getter), but you may pretty much view REST as the SQL of the Web, and RPC as stored procedures.

Re: When REST isn't Good Enough

#83

Post by SilasX »

bct wrote: post #60
SilasX wrote: post #57

Earlier quoted context omitted.

Indeed: the problem space being APIs. Feel free to point me to an example of fielding pointing to an API problem that shouldn't be RESTful.

No, the problem space being "scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components". This merely happens to overlap significantly with the requirements of public APIs. I have difficulty imagining your distance calculator needing any of those things, though.

>No, the problem space being "scalability of component interactions, ...

>I have difficulty imagining your distance calculator needing any of those things, though.

Right, because no one's stupid enough to use (or stick to the use of) REST for a distance calculator or any other algorithmically generated information. But make no mistake, scalability of component interaction is an issue, just a solved one (for those that see REST for what it is).

The solution is: specify an input scheme (for a hand calculator: put the first number, then plus, then the second number, then equals) and let the user choose the inputs. This saves you from the (intercomponent-unscalable) combinatorial explosion in which you have to give the user a link to every possible computation as they navigate the interface, and which is the REST method.

So, any exposed function in which you can't feasibly blast every possible input set over the network is REST-incompatible, so I guess the serious RESTers don't think you should do it. Which kinda makes it little more than a footnote.

Re: When REST isn't Good Enough

#84

Post by SilasX »

bct wrote: post #65
SilasX wrote: post #64

Earlier quoted context omitted.

That is not a RESTful solution, though: what resource is it acting on? What are the four CRUD operations for it? You have to come up with some added, unnecessary, implementation-exposing abstraction like "CityPair". (In which case "delete" could be ill-defined if, as would be wise, the distance is computed from a lat/long or road table lookup, and so there is no actual database entry that corresponds to the distance…

> what resource is it acting on? The distance between the two cities. > You have to come up with some added, unnecessary, implementation-exposing abstraction like "CityPair". This is a really weird thing to say. No, you don't. I have no idea why you would think that. > What are the four CRUD operations for it? [...] In which case "delete" could be ill-defined Not every method has to be valid for every resource. It's…

>>what resource is it acting on?

>The distance between the two cities.

Don't be cute. What server resource is it acting on? The value of the distances is (potentially) computed by some encapsulated algorithm -- you're not acting on that resource. The server resources that are touched are the two cities, and then whatever it does behind the scenes.

>This is a really weird thing to say. No, you don't. I have no idea why you would think that.

Because I'm not GETing a city, so I can't use the GET operation on the city resource; I have to make another resource to GET. Fine, it doesn't have to be a city pair: but there is a many-to-many mapping, which in REST-favoring frameworks (e.g. Rails), requires a separate table. By reducing everything to CRUD, you must create a new resource (type) for each new operation.

>(And POST/GET/PUT/DELETE is a very different concept from CRUD.)

That's a non-standard definition of "very different", considering that POST is create, GET is retrieve, PUT is update, and DELETE is delete.

Re: When REST isn't Good Enough

#85

Post by bct »

SilasX wrote: post #81
bct wrote: post #76

Earlier quoted context omitted.

> involves being told how to construct a URI The crucial thing that you're missing is that it's being told how to construct that URI in-band . Not in a piece of documentation that has to be hard-coded into the client.

So, once again, it turns out that REST reduces to RPC plus some advisable practices as soon as you point out how the original REST schema is woefully impractical. Not-REST: You can algorithmically generate requests for the information you want based on documentation. REST: You can algorithmically generate requests for the information you want based on documentation that's provided in the session . (Oh, and forget all…

No.

You're not listening, and you're not arguing in good faith.

Re: When REST isn't Good Enough

#86

Post by [deleted] »

SilasX wrote: post #84
bct wrote: post #65

Earlier quoted context omitted.

> what resource is it acting on? The distance between the two cities. > You have to come up with some added, unnecessary, implementation-exposing abstraction like "CityPair". This is a really weird thing to say. No, you don't. I have no idea why you would think that. > What are the four CRUD operations for it? [...] In which case "delete" could be ill-defined Not every method has to be valid for every resource. It's…

>>what resource is it acting on? >The distance between the two cities. Don't be cute. What server resource is it acting on? The value of the distances is (potentially) computed by some encapsulated algorithm -- you're not acting on that resource. The server resources that are touched are the two cities, and then whatever it does behind the scenes. >This is a really weird thing to say. No, you don't. I have no idea wh…

[deleted]

Re: When REST isn't Good Enough

#87

Post by SilasX »

bct wrote: post #85
SilasX wrote: post #81

Earlier quoted context omitted.

So, once again, it turns out that REST reduces to RPC plus some advisable practices as soon as you point out how the original REST schema is woefully impractical. Not-REST: You can algorithmically generate requests for the information you want based on documentation. REST: You can algorithmically generate requests for the information you want based on documentation that's provided in the session . (Oh, and forget all…

No. You're not listening, and you're not arguing in good faith.

I could say the same of you. Please tell me how I failed to accurately characterize the difference between RPC and REST with respect to defining requests whose entire working URI set can't feasibly be sent over the network.

Alternatively, explain how REST can simultaneously meet the constraints of "avoid combinatorial explosion of possible URIs to explicitly present" and "every resource is accessible by following server-provided links" and "avoid unnecessary bandwidth usage".

Re: When REST isn't Good Enough

#88

Post by SilasX »

BerislavLopac wrote: post #82
sopooneo wrote: post #78

Earlier quoted context omitted.

I'm sort of with you, though I've read quite a bit at this point and interacted with a number of APIs of varying degrees of "RESTfulness". The biggest question I wish the various tutorials would address is: why is REST a good idea? Why is this particular way of doing things better than others? And here's one thing I believe is true, that I have literally never seen in a REST tutorial: sometimes REST is not the best w…

"sometimes REST is not the best way to go. Sometimes an RPC architecture is better." I think that the full versions of there acronyms make a pretty good job of explaining what is best when. "REpresentational State Transfer": obviously, it transfers state , i.e. information about a certain resource at a given moment. "Remote Procedure Call": obviously, it calls a procedure , which may involve several state changes and…

>but you may pretty much view REST as the SQL of the Web, and RPC as stored procedures.

Indeed, but that just raises the question: what would possess you to write an app out of SQL calls rather than general functions? So then why do the Web equivalent thereof?

Re: When REST isn't Good Enough

#89

Post by BerislavLopac »

SilasX wrote: post #88
BerislavLopac wrote: post #82

Earlier quoted context omitted.

"sometimes REST is not the best way to go. Sometimes an RPC architecture is better." I think that the full versions of there acronyms make a pretty good job of explaining what is best when. "REpresentational State Transfer": obviously, it transfers state , i.e. information about a certain resource at a given moment. "Remote Procedure Call": obviously, it calls a procedure , which may involve several state changes and…

>but you may pretty much view REST as the SQL of the Web, and RPC as stored procedures. Indeed, but that just raises the question: what would possess you to write an app out of SQL calls rather than general functions? So then why do the Web equivalent thereof?

You don't, of course. What you do is build an app which is using REST to store data somewhere online, and the app itself may be in the user's browser, on a mobile phone or anywhere else for that matter.

Re: When REST isn't Good Enough

#90

Post by SilasX »

BerislavLopac wrote: post #89
SilasX wrote: post #88

Earlier quoted context omitted.

>but you may pretty much view REST as the SQL of the Web, and RPC as stored procedures. Indeed, but that just raises the question: what would possess you to write an app out of SQL calls rather than general functions? So then why do the Web equivalent thereof?

You don't, of course. What you do is build an app which is using REST to store data somewhere online, and the app itself may be in the user's browser, on a mobile phone or anywhere else for that matter.

Definitely. Just pass that memo along to the "apps should work purely through REST API calls" crowd.
Post reply on HN