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

21–30 of 58 posts

Re: Don't Build APIs

#21

Post by jbri »

btilly wrote: post #19
cek wrote: post #18

Earlier quoted context omitted.

OP here. I think this is very naive/utopian. Yes, be super focused in your design. Yes, only expose APIs you have clear use cases for. Yes, keep the surface area as small as possible. Yes, have very focused requirements. Yes, document the hell out of things. Yes, implement strong parameter validation and other things to try to reduce the chance people do bad things. Do all these things and more (these are all part of…

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?

Re: Don't Build APIs

#22

Post by 6ren »

sophacles wrote: post #8
mattmanser wrote: post #6

Earlier quoted context omitted.

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.

If you have your kill-date iterate rapidly enough, and advertise it well enough, people who build products on your API will keep up, or the competitors will and take their business. Heck, if you want to be really hand-holdy about it, have an warnmesage attribute in your returns that mentions various issues, and start throwing deprication warnings some $time before the kill date as a reminder. And the number of bugs a…

Or customers will switch to a competitor's API that doesn't keep trashing their app with "improvements' that are not usable for that specific app.

But your proposal is interesting: if things are improving all the time, API-users need to be upgrading all the time and adapting to the new features anyway - so any incompatibility necessary for those features is no problem.

It depends on the phase of market (new, growth, mature, stagnating) for that specific API. At the moment, most web-APIs usages are "new".

Re: Don't Build APIs

#23

Post by cek »

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 little Python and a Heroku account.

But something else has changed along the way: Composability.

Yes, I worked on COM, OLE, ActiveX and all that crap. I was thinking deep thoughts about composable software back in the stone ages (and even then, it had all already been done by others smarter than I in the 70s & 80s).

But today it is REAL. The Web technology stack has actually, finally, enabled massive distributed systems composed of loosely coupled components from multiple independent parties! The dream of my computing youth has become reality!

These things are connected by APIs.

(Which, by the way are not just function calls. A API can be a REST end-point, a file format, or a database schema, amongst other things).

Yes, you as an API provider can choose to deprecate your API anytime you want. Use kill-dates, warnmessages, etc... You can even create new, independent & parallel versions. It will help.

But you will find that someone else has built something that uses your API, that exposes its OWN API and now there's a 3rd party indirectly dependent on you. Be prepared for it.

APIs are actually easy to build. That is the problem. The solution is to realize that statement is actually false.

Re: Don't Build APIs

#25

Post by planckscnst »

georgemcbay wrote: post #15
mattmanser wrote: post #6

Earlier quoted context omitted.

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.

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 will result from developers being required to work harder to port their software.

Re: Don't Build APIs

#26

Post by grogs »

georgemcbay wrote: post #15
mattmanser wrote: post #6

Earlier quoted context omitted.

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.

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…

Facebook making breaking changes does piss people off. It's interesting that it doesn't kill the apps. I can't remember any single change Facebook have made - possibly just because tere's so many - but I do remember when twitter made everyone switch to OAuth. People complained about that kill date.

Re: Don't Build APIs

#27

Post by asif »

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.

Re: Don't Build APIs

#28

Post by tmurray »

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…

Your API documentation (or specification if you have one) is not your specification. Your API implementation is your specification, especially if you are the only provider of the API. I realize how trite that sounds, but it's true. Defensive API design (make it REALLY HARD to have undocumented tricks that developers can use in productive ways) is dramatically harder than API design is in the first place, and I still guarantee you'll screw it up for any moderately expressive API.

It's not just an issue of parameter validation or well-defined calls; it's the interactions between calls where this is hard. It's issues of ordering, timing, when you can secretly skip synchronization because you know the API will synchronize just enough for you to get away without something more heavyweight, things like that. And then when you have paying customers? Yeah, you can't break their code, even if it's bad, because if you do you won't have customers for very long.

Re: Don't Build APIs

#29

Post by loverobots »

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…

Having a reasonable end of life on support never hurt apple.

Just because the iPhone is doing great, doesn't mean businesses and other slow movers avoid Apple because of this. My point is, we don't know if this hurts Apple or not.

Re: Don't Build APIs

#30

Post by anonymoushn »

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…

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