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

61–70 of 94 posts

Re: When REST isn't Good Enough

#61

Post by edanm »

michaelfairley wrote: post #52
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.

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

Interesting. I wasn't sure about buying it, but ended up purchasing. Only after realizing that it was by Steve Klabnik, a name I recognize, probably from HN. I wonder why there isn't more info on the front page, even a sample/TOC would be nice.

I'll be going through it tomorrow, if I remember I'll come back to post a mini review.

Re: When REST isn't Good Enough

#62

Post by drivebyacct2 »

jebblue wrote: post #54
drivebyacct2 wrote: post #41

Earlier quoted context omitted.

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

I meant the HTTP spec which is where GETs specified.

Re: When REST isn't Good Enough

#63

Post by shawn-butler »

dan_manges wrote: post #32
scanr wrote: post #4

Braintree have made an interesting choice in keeping their REST API private and requiring customers use their client libraries. I think they could both have client libraries that they promote as well as a public REST API. Breaking down their reasons: Security - agree with them on this, the more they can help their users make their systems secure the better. Not sure if it should preclude a public REST API but certain…

I'm a developer at Braintree. The challenge with maintaining backwards compatibility on the server side is handling the wide variety of possible inputs into the system. It's hard to write tests that account for all of them. I've seen a couple of cases where backwards compatibility can be broken in unexpected ways. For one application that we built at Braintree, we had a client that was sending us an application/x-www…

If you are going to make the decision and commitment to supply client SDKs instead of a RESTful API why choose to implement the back-end as a http service? It is now hidden entirely by abstraction from clients and there are lots of efficiencies to be gained by using a custom protocol.

Did you evaluate whether a RPC pipe or distributed filesystem was a better fit?

Re: When REST isn't Good Enough

#64

Post by SilasX »

bct wrote: post #59
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.…

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

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 between the cities.) That's the problem with REST: it doesn't avoid the complexity of RPC; it just crams it into ever-more-creative resource types.

Most API users (sorry, "consumers") would prefer they just be told the format in which to ask for the data, not have to re-discover it through gradually-exposed paths each time.

Re: When REST isn't Good Enough

#65

Post by bct »

SilasX wrote: post #64
bct wrote: post #59

Earlier quoted context omitted.

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

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 a total non-issue that you can't delete a distance.

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

Re: When REST isn't Good Enough

#66

Post by pbreit »

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

Not true.

GET /distance?cities=San+Francisco,Los+Angeles would suffice. city1=modesto&city2=fresno might be preferred if you wanted to support form submissions, too.

Query strings are perfectly restful.

Re: When REST isn't Good Enough

#67

Post by grncdr »

tlrobinson wrote: post #44

It's a shame there isn't some simple standard (de-facto or otherwise) way of documenting REST APIs such that an idiomatic client library for each language could be generated automatically. The OPTIONS method is a really underused part of HTTP and would be great for this purpose: http://zacstewart.com/2012/04/14/http-options-method.html

Check out github.com/RestDoc/specification, it's a project that got started after a few people (myself and Zac included) realized we were all solving the same problem. It's been languishing in relative obscurity because most of us don't have the bandwidth to properly promote it, but more contributions are very welcome!

Re: When REST isn't Good Enough

#68

Post by toomuchtodo »

edanm wrote: post #61
michaelfairley wrote: post #52

Earlier quoted context omitted.

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

Interesting. I wasn't sure about buying it, but ended up purchasing. Only after realizing that it was by Steve Klabnik, a name I recognize, probably from HN. I wonder why there isn't more info on the front page, even a sample/TOC would be nice. I'll be going through it tomorrow, if I remember I'll come back to post a mini review.

This. After seeing the URL posted above, I clicked the link just to see if it was Steve's book. Disappointed he doesn't put his name prominently on the landing page.

Re: When REST isn't Good Enough

#69

Post by Ramone »

jebblue wrote: post #54
drivebyacct2 wrote: post #41

Earlier quoted context omitted.

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

GET being cacheable/idempotent is part of the HTTP spec, and has nothing to do with REST: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13...

Re: When REST isn't Good Enough

#70

Post by ProblemFactory »

bct wrote: post #58
andrewflnr wrote: post #56

Earlier quoted context omitted.

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

That tagline may explain the benefits of REST, but it doesn't really explain at all which problems REST is well-suited for and which not.

I've found that REST design is great for problems where the most visible abstraction is a document or an object (with operations or functions as secondary). It doesn't really fit problems where the most common abstraction is a function call (with the arguments a secondary concern).

Post reply on HN