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

51–60 of 94 posts

Re: When REST isn't Good Enough

#51

Post by edanm »

mikeknoop wrote: post #16

We (Zapier) are in a particularly good place to comment on this. We have implemented about 70 very diverse web APIs in-house. Early on, we used client libraries because they were easy and convenient. That decision bit us, hard. (Most) client libraries are un-maintained, opaque, and difficult to extend. We spent many months ripping every client library out down to the raw requests. We are in a unique position because…

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.

Re: When REST isn't Good Enough

#52

Post by michaelfairley »

edanm wrote: post #51
mikeknoop wrote: post #16

We (Zapier) are in a particularly good place to comment on this. We have implemented about 70 very diverse web APIs in-house. Early on, we used client libraries because they were easy and convenient. That decision bit us, hard. (Most) client libraries are un-maintained, opaque, and difficult to extend. We spent many months ripping every client library out down to the raw requests. We are in a unique position because…

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.

Not your typical book, but it's very good: http://designinghypermediaapis.com/

Re: When REST isn't Good Enough

#53

Post by SilasX »

bct wrote: post #48
SilasX wrote: post #46

Earlier quoted context omitted.

>It's a pattern that comes with a lot of really useful benefits. Sure, but people can implement that pattern without buying into the whole clumsy REST edifice. For example, a strict reading of REST (and RESTers support such readings!) would tell me that if I have an API that takes two cities and returns the distance between them, then I must expose a URI pointing to every combination of cities . See here: http://roy.…

Nobody ever said that you should use REST if it doesn't suit the problem you're trying to solve.

But there are people that believe REST suits every API problem, even when accumulated wisdom says it doesn't suit the problem (cough Roy Fielding).

Re: When REST isn't Good Enough

#54

Post by jebblue »

drivebyacct2 wrote: post #41
Domenic_S wrote: post #38

Earlier quoted context omitted.

I cringe a little bit whenever someone tries to present caching as simple or straightforward.

I don't see that anywhere in the post. All I saw was "GET"s shouldn't modify state and should be cacheable. That seems perfectly in line with the spec.

The only problem I have with your comment is that REST is not specified, it's a style:

http://en.wikipedia.org/wiki/Representational_state_transfer

Re: When REST isn't Good Enough

#55

Post by bct »

SilasX wrote: post #53
bct wrote: post #48

Earlier quoted context omitted.

Nobody ever said that you should use REST if it doesn't suit the problem you're trying to solve.

But there are people that believe REST suits every API problem, even when accumulated wisdom says it doesn't suit the problem ( cough Roy Fielding).

No, he makes it quite clear that it's a solution designed for a particular problem space. You're debating a straw man.

Re: When REST isn't Good Enough

#56

Post by andrewflnr »

bct wrote: post #48
SilasX wrote: post #46

Earlier quoted context omitted.

>It's a pattern that comes with a lot of really useful benefits. Sure, but people can implement that pattern without buying into the whole clumsy REST edifice. For example, a strict reading of REST (and RESTers support such readings!) would tell me that if I have an API that takes two cities and returns the distance between them, then I must expose a URI pointing to every combination of cities . See here: http://roy.…

Nobody ever said that you should use REST if it doesn't suit the problem you're trying to solve.

Part of the debate is what problems REST is suited to solve. While most evangelists will never come out and say, "you should use X for everything," they will try to fit it into whatever situation it will "reasonably" fit into, which is probably a bigger domain than the problems it's "best" for.

Re: When REST isn't Good Enough

#57

Post by SilasX »

bct wrote: post #55
SilasX wrote: post #53

Earlier quoted context omitted.

But there are people that believe REST suits every API problem, even when accumulated wisdom says it doesn't suit the problem ( cough Roy Fielding).

No, he makes it quite clear that it's a solution designed for a particular problem space. You're debating a straw man.

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.

Re: When REST isn't Good Enough

#58

Post by bct »

andrewflnr wrote: post #56
bct wrote: post #48

Earlier quoted context omitted.

Nobody ever said that you should use REST if it doesn't suit the problem you're trying to solve.

Part of the debate is what problems REST is suited to solve. While most evangelists will never come out and say, "you should use X for everything," they will try to fit it into whatever situation it will "reasonably" fit into, which is probably a bigger domain than the problems it's "best" for.

The thesis lays out in detail what REST provides:

"REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems."

The existence of these properties should be fairly evident when you examine the constraints.

I think large part of the confusion comes from not recognizing the difference between "Any system can be built in a RESTful style" (this is true) and "Every system should be built in a RESTful style" (this is a straw man).

Re: When REST isn't Good Enough

#59

Post by bct »

SilasX wrote: post #46
enjo wrote: post #13

Earlier quoted context omitted.

The REST version makes it clear that you are dealing with operations on a resource. The URL identifies a thing in a consistent way, while the method and corresponding data allow you to manipulate it. The biggest benefit comes when building a cache architecture. RESTful API's (when properly implemented) come with built-in assumptions about idempotency. You end up in a place where you can easily cache GET requests whil…

>It's a pattern that comes with a lot of really useful benefits. Sure, but people can implement that pattern without buying into the whole clumsy REST edifice. For example, a strict reading of REST (and RESTers support such readings!) would tell me that if I have an API that takes two cities and returns the distance between them, then I must expose a URI pointing to every combination of cities . See here: http://roy.…

> 1. [send a link for each possible combination]

> 2. instruct clients on how to construct appropriate URIs

> 3. link a URI for the starting city and then from there link them to possible choices of the second city

All three of these are possible RESTful solutions, and I can imagine situations where each of them might make sense.

But what you're probably looking for is something like this:

  ......
(Using URL templates is a potentially simpler way to achieve the same thing). This is, of course, your solution 2.

There are tradeoffs involved in using this style. Are they worth it? That really depends on the larger system and all kinds of details which you've left out.

Re: When REST isn't Good Enough

#60

Post by bct »

SilasX wrote: post #57
bct wrote: post #55

Earlier quoted context omitted.

No, he makes it quite clear that it's a solution designed for a particular problem space. You're debating a straw man.

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.

Post reply on HN