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

Don't Build APIs

ceklog.kindel.com

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Don't Build APIs

#41

Post by ryanherman »

tmurray wrote: post #4

This post is very accurate. I build APIs for a living (CUDA), and this lines up pretty well with my experience. Writing APIs is very tough, you will get a lot of things wrong, and the fixes available to you after you realize your mistake are all ugly at best. One quick example: In CUDA, you have to explicitly copy memory to and from the GPU. We have two basic kinds of memcpy functions--synchronous and asynchronous. A…

Crazy, you work for Nvidia? I love using CUDA for VRAY rendering. It still lacks a ton of the material support but its getting there. From your development, how much more needs to be added to CUDA and Video Cards to get more accurate renderings with full support of materials? I know VRAY has figured out some amazing ways to get around this and support multisided material recently.

Re: Don't Build APIs

#42

Post by yxhuvud »

cek wrote: post #23

OP here. When I wrote this post, I didn't imagine so many people would react by saying, essentially "Screw the customers. Just break 'em." One of the reasons I have my panties in wad over this topic is the Web has made it far easier for people to create APIs that get used by others. Back in the olden-days you HAD to be Microsoft or similar to get the kind of traction a kid in his parent's basement can get with a litt…

However, you also have to realize that the business effect on Microsoft if their API break is vastly different than the one on Twitter if their API breaks.

If Microsoft break their API's, then people might not upgrade their versions.

Will people stop using Twitter if they break their API's? Definitely not, so why should they bother if some third part have to pay to fix their code?

Re: Don't Build APIs

#43

Post by gfodor »

asif wrote: post #27

Build the best API you know how to build and ask questions later. If your business is doing well, then supporting your API forever is a high quality problem.

This is often good advice, but not in this case. Versioning your API is a trivial thing to do from the beginning and has massive consequences down the road. Some things are worth getting right in the beginning.

Re: Don't Build APIs

#44

Post by alexchamberlain »

cek wrote: post #33
ssanders82 wrote: post #31

Earlier quoted context omitted.

OP, I really don't want to be that guy, and I don't know why I'm being that guy tonight, but regarding your sentence, "I then spent hours pouring over..." - come on man, it's poring.

I don't mind you being that guy at all. I consider myself to be an ok writer with a reasonable vocabulary. I never knew it wasn't pouring. Consider me educated. Thanks. :-)

poring and pouring have different definitions - so pouring is correct for liquid, and poring is correct for poring over.

Re: Don't Build APIs

#45

Post by alexchamberlain »

jbri wrote: post #21
btilly wrote: post #19

Earlier quoted context omitted.

I agree with all of what you just said. But I think that the post is not a good demonstration of that. Microsoft failed at keeping the surface area as small as possible. When their surface area expanded to a hack to deal with Adobe's hack of replacing code behind Microsoft's back, they went into very dangerous territory.

If an end-user upgrades their operating system, and Adobe WhateverIUse stops working, who do they blame?

Adobe.

Re: Don't Build APIs

#46

Post by stickfigure »

This boils down to a simple question:

Are most of your API users ahead of you, or behind you?

If you have an immature API with a smallish number of users, and you think that incompatible changes in the API will improve adoption with the vast bulk of your (not-yet-on-board) potential market, then go ahead, break the API.

If the only reason people use your API is because of its legacy -- if you think that by changing your API people will wake up from their inertial slumber and investiate your superior competitors, then don't break your API under any circumstances.

Obviously there are grey points in between, and a series of small breaking changes will be worse than occasional large breaking changes. But by and large, the success of your platform will depend on its utility, not legacy compatibility. This is why stripe and wepay will eventually conquer paypal, why python will continue to be a vibrant community, why java will eventually fade to cobol-like obscurity, and why Microsoft Windows is fundamentally doomed. It's hard to look backwards and forwards at the same time.

Re: Don't Build APIs

#47

Post by Robin_Message »

alexchamberlain wrote: post #45
jbri wrote: post #21

Earlier quoted context omitted.

If an end-user upgrades their operating system, and Adobe WhateverIUse stops working, who do they blame?

Adobe.

That is a wish, not the truth. It is self-evident that if I upgrade my OS and an app stops working, it is the upgrade's fault. I'm sure there is a "law" of "whoever last changed something broke it."

Re: Don't Build APIs

#48

Post by mtts »

jbri wrote: post #21
btilly wrote: post #19

Earlier quoted context omitted.

I agree with all of what you just said. But I think that the post is not a good demonstration of that. Microsoft failed at keeping the surface area as small as possible. When their surface area expanded to a hack to deal with Adobe's hack of replacing code behind Microsoft's back, they went into very dangerous territory.

If an end-user upgrades their operating system, and Adobe WhateverIUse stops working, who do they blame?

It's not as simple as that. If it's just Adobe WhateverIUse that breaks, sure, people will blame Adobe. But if it's Adobe WhateverIUse that breaks AND WordPerfect WhateverSomeoneElseUses and maybe also Borland SomethingSomeoneElseYetAgain uses word will get around that the new operating system "breaks things" and people will stay away from it.

Even if noone will ever use all three of the broken apps.

In this sense, maintaining backwards compatibility is simply a matter of reputation management.

Re: Don't Build APIs

#49

Post by dasil003 »

cek wrote: post #23

OP here. When I wrote this post, I didn't imagine so many people would react by saying, essentially "Screw the customers. Just break 'em." One of the reasons I have my panties in wad over this topic is the Web has made it far easier for people to create APIs that get used by others. Back in the olden-days you HAD to be Microsoft or similar to get the kind of traction a kid in his parent's basement can get with a litt…

I agree the mentality of "just break 'em" is wrong. But it's not so black and white. What you described is the extreme end of the spectrum that Microsoft is on. Clearly this is a pathological case where you commit to support abuse of your API. The alternative in this case would have been to tell Adobe not to do that earlier on. I understand why Microsoft operates that way, and I do believe it's an admirable goal, but you don't have to paint yourself into this corner. There are alternatives that are more subtle than screwing the customer. This gray area is what the thesis of your article skips over.

It's still a great story though.

Re: Don't Build APIs

#50

Post by alexchamberlain »

Robin_Message wrote: post #47
alexchamberlain wrote: post #45

Earlier quoted context omitted.

Adobe.

That is a wish, not the truth. It is self-evident that if I upgrade my OS and an app stops working, it is the upgrade's fault. I'm sure there is a "law" of "whoever last changed something broke it."

So, it's the users fault then?
Post reply on HN