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

41–50 of 94 posts

Re: When REST isn't Good Enough

#41

Post by drivebyacct2 »

Domenic_S wrote: post #38
enjo wrote: post #35

Earlier quoted context omitted.

GET requests, by definition, should have no side-effects. Which makes them cacheable. Many browsers cache GET requests by default unless cache-control tells them not to. You can most definitely write a GET request that contains side-effects, but that's because you're doing it wrong (tm). Imagine if your function names had data in the call path MyCourse.32423.Delete(); that doesn't look very good does it? 32423 would…

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.

Re: When REST isn't Good Enough

#42

Post by drivebyacct2 »

pixie_ wrote: post #34
bct wrote: post #28

Earlier quoted context omitted.

APIs that ignore the realities of distributed computing and that each have different special-snowflake wire formats requiring tedious documentation: the worst of both worlds.

I'm not arguing against implementing an RPC if that's what you need. My original post describes a super set of JSON-RPC.

Your post implies a pseudo-free-for-all and defeats the purpose of having a conversation about a standard exchange format.

You basically have said "I want to make it work the way I want it and I don't care if it's non-standard and unintuitive.". You're welcome to do that, but everyone who needs to work with it will hate you. And when you've been working on it for 2 months, or take a two month break, you'll come back and hate yourself too...

Re: When REST isn't Good Enough

#43

Post by politician »

mixedbit wrote: post #21
pixie_ wrote: post #5

I don't like REST. Making a call to a server should be like calling a function anywhere else - you have your parameters and return value. In REST the parameters are spread over 3 places, the action, the url and the post parameters themselves. It's a much better design to combine all your parameters in one place and keep things simple, for example - REST version: UPDATE /course/324234 { description: "This is a level 1…

IMO the biggest benefit of REST vs RPC is reduced coupling between the client and the server. With RPC client needs to be explicitly aware of all methods and parameters that the server supports. With well designed REST interface this is not the case, you can have a generic client that does not need to be explicitly coded to support the specific service. REST interfaces are more difficult to design than RPC interfaces…

Rich Hickey (Clojure) has a presentation about the differences between simple and easy. If you have the time, it's worth it.

http://www.infoq.com/presentations/Simple-Made-Easy

Re: When REST isn't Good Enough

#44

Post by tlrobinson »

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

Re: When REST isn't Good Enough

#45

Post by elarkin »

MatthewPhillips wrote: post #23
bguthrie wrote: post #10

Note that this isn't a critique of the REST architectural style; rather, it documents their decision to prefer supplying clients with prebuilt libraries rather than a public API that their respective language communities can use to build their own. You could read the source to any one of their client libs and infer the rough structure of their services, so it's not all that private; they're simply choosing to leave w…

I have no knowledge of what BrainTree does, but if I'm picking a service with an API, I'm picking the one that is easiest to learn (preferably there is little that needs to be learned), I'm not picking one that requires me to switch languages -- or just as bad, locks me into one of a few languages I'm currently using.

BrainTree does payments. They have concerns about security that most apps do not. Who really cares if bugged timeout/retry logic makes your app post twice to facebook? Probably no one. Who cares if bugged timeout/retry logic makes your app bill them twice? Probably everyone.

BrainTree and you may not make the same decision, and you both could be right.

Re: When REST isn't Good Enough

#46

Post by SilasX »

enjo wrote: post #13
pixie_ wrote: post #5

I don't like REST. Making a call to a server should be like calling a function anywhere else - you have your parameters and return value. In REST the parameters are spread over 3 places, the action, the url and the post parameters themselves. It's a much better design to combine all your parameters in one place and keep things simple, for example - REST version: UPDATE /course/324234 { description: "This is a level 1…

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.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...

>>A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) ... From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user’s manipulation of those representations. ... [Failure here implies that out-of-band information is driving interaction instead of hypertext.] [emphasis mine]

So, 1000 cities, you must send a million links over the network rather than 1000 possible parameters plus the formatting.

Now, some RESTers assure me that, no, you can somehow communicate to the user that [prefix] / [first city] / [second city] will get you that answer; that a server can "instruct clients on how to construct appropriate URIs".

Fine, but then we're right back to custom, author-documented APIs and RPCs: "to do that, format the call this way". Right back where we were before trying to force-fit everything into a CRUD mold with increasingly bizarre tables just to make all the calls work.

Or maybe a REST purist would tell me that I'm supposed to link a URI for the starting city: [root]/distances/[start city]/, and then from there link them to possible choices of the second city: [root]/distances/[start city]/[end city]/ .

Fine, but why jump through two pointless hoops, when I know what I want, and I prefer to just send one request rather than pointlessly spend bandwidth navigating a path I don't care for?

Re: When REST isn't Good Enough

#47

Post by caseysoftware »

bguthrie wrote: post #10

Note that this isn't a critique of the REST architectural style; rather, it documents their decision to prefer supplying clients with prebuilt libraries rather than a public API that their respective language communities can use to build their own. You could read the source to any one of their client libs and infer the rough structure of their services, so it's not all that private; they're simply choosing to leave w…

At Twilio, our REST API is fully documented but we still encourage people to use our helper libraries as much as possible.

It's not because we'd like to document the API less, but because there are related things - http connections, auth, etc - that need to be handled and it's easier to have the library do them. Further, the library serves to wrap the API in the idioms appropriate for the language. This may include data structures, but also includes things like variable names.

That way you can focus on your app in your chosen.. and only dig into the abstraction if you choose to.

Re: When REST isn't Good Enough

#48

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

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

Re: When REST isn't Good Enough

#49

Post by josephlord »

makmanalp wrote: post #15
benatkin wrote: post #9

Earlier quoted context omitted.

> Making a call to a server should be like calling a function anywhere else - you have your parameters and return value. What you've described is RPC, which has been around for ages. Why do you think REST became a popular alternative to RPC?

Because the de-facto transport for it is HTTP, which a) People know b) Is simple and predictable c) Has had support from every language on the face of the earth, for ages and thus d) Takes 1 minute to get up and running with, as opposed to, say, SOAP etc. e) Fits the CRUD model fairly nicely, which comprises the majority of web apps. Nothing to do with one man's phd thesis or anything (that came YEARS after he wrote…

You missed: gets through proxies and firewalls.

Unless that is what you mean by (b).

Re: When REST isn't Good Enough

#50

Post by hennk »

mikeknoop wrote: post #30
jeremyjh wrote: post #19

Earlier quoted context omitted.

Can you respond directly to some of the points raised in the article? For example, ensuring SSL certs are validated?

Sure. I'll start with this: as far as client libraries go, Braintree is doing it right. Because it's the only thing they support, they are incentivized to make sure it is feature complete and bug free. SSL: It is not the onus of the vendor to ensure people are properly securing requests. I have seen horrendous things done in the name of "security" but it only adds headaches. Fix this at the client level. SSL everywhe…

I can understand that a payment gateway takes security more serious, as it can directly affect their business if clients handle SSL wrongly.

Maybe a kind of chaos-monkey for API connections could help? Every now and then the API returns a wrong SSL certificate. If the client ignores this, they could notify the customer, or directly block further access until the problem is solved? :)

Post reply on HN