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

31–40 of 58 posts

Re: Don't Build APIs

#31

Post by ssanders82 »

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…

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.

Re: Don't Build APIs

#32

Post by ramanujan »

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…

Two ideas on your post regarding potential technical resolutions.

First, in a web environment, one is probably logging all API calls and their effects on the server side. With Windows, you couldn't do that as your users were hitting local code rather than an MS server. This makes deprecation of older APIs much easier, in part because you can see which of your functions a particular API user is calling and in which order. Done right, these backend metrics will make it easy to identify the most popular use cases as well as functions that aren't used much.

Additionally, there was an interesting HN post from a few days back on self-describing APIs[1]. If this catches on, it will also make it easier to deprecate old APIs, especially if the OPTIONS request returns JSON. With a little bit of reflection up front, client code can then determine the most up to date way to achieve the effect they are trying to get with this API call. This may slow down client code (requiring one or more redirects up front) but won't crash it. Apple's support of Rosetta for PPC shows that slow emulation is a good intermediate between outright breakage (a la Facebook) and infinite grandfathering (a la early MS).

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

Re: Don't Build APIs

#33

Post by cek »

ssanders82 wrote: post #31
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…

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. :-)

Re: Don't Build APIs

#34

Post by bwood »

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…

Thanks for your work on CUDA, it's really a great tool! My one hope is that Nvidia decides to make it a direct competitor to OpenCL by allowing it to target different platforms (though I recognize that it's not completely up to Nvidia and requires cooperation from others).

Re: Don't Build APIs

#36

Post by groby_b »

mattmanser wrote: post #6
sophacles wrote: post #3

At some point, we need to kill the myth of backwards compatible. This has caused more problems than it fixes. Further, at this point in history, app updates are trivial and built into everything, so retaining backwards compatibility is not so much of a necessity. When designing APIs, use versions and have a kill date in place. Even if you don't change the API, release the same one under a new version number. Kill acc…

Myth? MS built a very successful business on it. You know what happens when you get kill dates? One day all of a sudden half the web will stop working. There's a reason why people start back flipping to support out of date calls. Customers don't care why your software just broke or whose fault it was, all they care about is it broke.

Yeah, Apple has no success whatsoever with their aggressive deprecation strategy :)

Re: Don't Build APIs

#37

Post by barrkel »

planckscnst wrote: post #25
georgemcbay wrote: post #15

Earlier quoted context omitted.

I'm actually quite fond of the way Microsoft historically bent over backwards for backward compatibility, but OTOH Facebook is also very successful and has a very successful ecosystem of third-party users of their APIs. Facebook is like the anti-Microsoft in that they randomly change and break their APIs at such an alarming rate that you have to wonder if they are intentionally fucking with you if you code against th…

I think developers tend to love backward-compatability while users hate it. As a developer, it means we don't have to keep digging out the old projects and porting them to the new API. As a user, it means we are left with systems that have many years of cruft and with features being held back from systems because they couldn't make it backward-compatabile. I think most users are willing to pay any higher price that w…

Users love it when their software still works even after they've upgraded another bit of the overall system.

Re: Don't Build APIs

#38

Post by kstenerud »

btilly wrote: post #14

The key problem here is that "backwards compatibility" means "backwards compatibility for people abusing the API in undocumented ways". Don't do that. That way lays insanity. Be very, very clear up front that you will break backwards compatibility for those folks. Don't sweep it under the table, be very vocal about having done it. There will be short term pain as important customers (eg Adobe) learn the hard way that…

If they'd done that to the 6502 CPU and variants, every single non-trivial game or program would have broken.

Behind almost every successful API is a big ugly mess of backwards compatibility to keep customers happy.

Re: Don't Build APIs

#39

Post by dvhh »

anonymoushn wrote: post #30
planckscnst wrote: post #25

Earlier quoted context omitted.

I think developers tend to love backward-compatability while users hate it. As a developer, it means we don't have to keep digging out the old projects and porting them to the new API. As a user, it means we are left with systems that have many years of cruft and with features being held back from systems because they couldn't make it backward-compatabile. I think most users are willing to pay any higher price that w…

As a developer, I would rather have my code break than continue to use a terrible API.

How about fixing your application, because your terrible API were deprecated, for an application that is quite old, bit still in support ? (and of course for free, because client don't expect to pay for a compatibility fix).

Re: Don't Build APIs

#40

Post by chii »

sophacles wrote: post #12
cek wrote: post #9

Earlier quoted context omitted.

I think sophacles is onto something here. In my post I tried to make it clear that backwards compatibility is a challenge for successful APIs. However, I guess if you don't want to make your APIs successful you can do all kinds of things that make them harder to use, like putting in draconian kill-dates, warnmessages, etc... Make sure your documentation is extra-long and wordy too while you're at it. Because, sophacl…

This is a false dilemma. Just because you set up some opposing conditions: backwards compatibility or unsuccessful api doesn't actually make it true. Just an assertion. Having a reasonable end of life on support never hurt apple. There are lots of things that I can no longer run on the latest version of OSX. This happens every time the OS upgrades. Except of course they don't use versioned APIs, so it is much less pl…

"There are lots of things that I can no longer run on the latest version of OSX. This happens every time the OS upgrades."

This is what i hate about osx - they freaking change the OS drastically, and my apps break. Sure, there might be a new version, but when i compare mac OSX to windows, windows kicks ass because you know what? i can _still_ run crap that i used to run in win95!

Post reply on HN