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

API Half-lives

gabrielweinberg.com

Post reply on HN
Print view View original

21–30 of 45 posts

Re: API Half-lives

#21

Post by jsdalton »

losvedir wrote: post #20
jsdalton wrote: post #17

Earlier quoted context omitted.

This is true, although the "rule" in this case isn't entirely inconsistent: life -> lives wife -> wives elf -> elves half -> halves leaf -> leaves

Except chief -> chiefs brief -> briefs Maple Leaf -> Maple Leafs (Canadian Hockey team)

Yeah, my point wasn't so much that there are not exceptions, but that there are frequent patterns in the English language.

Rather than throwing up your hands in defeat and saying, "The English language is totally inconsistent; the only way to learn it is to memorize each arbitrary word form," the key is to familiarize yourself with these patterns so that at a minimum you can make a better guess next time.

Hopefully, WA learned today not just that the plural of "life" is "lives" but that, in general, when a noun ends in -f or -fe it usually changes to -ve. So if tomorrow he sees a sign that says "5 loaves of bread for $1" it won't catch him off guard like the title of this submission did.

Re: API Half-lives

#22

Post by eCa »

SimHacker wrote: post #16

Speaking of software half-lives: "Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. Basically, a lot of the problems that computing has had in the last 25 years comes from systems where the designers were trying to fix some short-term thing and didn’t think about whether the idea would scale if it were adopted. There should be a half-life on software so old…

I would think that the number of big sites that is/were built on Perl (IMDb, Amazon, ...) would be a counter point to that.

Of course, it's not the right tool for everything - far from it - but it is a Swiss army knife.

Re: API Half-lives

#23

Post by brlewis »

bryanh wrote: post #14

All API's are not made equal. Some may not be around in 2 years, some 10 years, but in the time you are forced to work with some of them, you might lose your sanity. I'm working with pretty much every type of API through my startup Zapier.com and some of these API's I wouldn't wish upon anyone except maybe the deeply masochistic coder. They suck. I suppose that's good for us. However, we aggregate data from many doze…

I mostly agree with you, but think XML is OK for a read-only API if your data fits RSS or Atom syndication.

Re: API Half-lives

#24

Post by mutagen »

API churn isn't limited to small companies. The FedEx shipping API is on version 9 and my last conversation with their developer support indicated they are currently ending support for version 5 and supporting versions 6 through 9. I certainly understand that business requirements, security standards, and development practices change and that it doesn't make sense for them to support what they were doing in 1995. However, I'd expect a little bit of what Google is doing [1] in trying to build sustainable APIs. On the other hand, maybe it is a good thing for security and IT practice to have a forced requirement that the software and systems from 10 years ago change.

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

Re: API Half-lives

#25

Post by apievangelist »

ksri wrote: post #8

>> With so many startups, there are often several choices in any given category. And having several choices is a great thing. When I integrate with an external API, I look at 2-3 other APIs as well. I then write an interface based on the common features / constructs available across similar APIs. Then I write program to that interface. If the external provider dies, at least I have an easy path to switch to another p…

I smell opportunity for API providers to step up and provide Plan B and C service for the very commoditized types of APIs.

Model the API design after the leader... similar to how some have done with Delicious, AWS, etc.

I like your strategy.

Re: API Half-lives

#26

Post by apievangelist »

Gabriel's and everyones comments are great...definitely an area that needs constant discussion.

I can't think of any industry where your vendor / supplier guarantees it will be there forever and never change.

Even with contracts and commitments, the world moves forward.

We are just moving forward at faster and faster rates. I think there is a lot of opportunity here for API owners to provide copycat services for redundancy.

Also lots of opportunity to really keep interfaces dead simple and easy to integrate, adapt and change.

Re: API Half-lives

#27

Post by perigrin »

losvedir wrote: post #20
jsdalton wrote: post #17

Earlier quoted context omitted.

This is true, although the "rule" in this case isn't entirely inconsistent: life -> lives wife -> wives elf -> elves half -> halves leaf -> leaves

Except chief -> chiefs brief -> briefs Maple Leaf -> Maple Leafs (Canadian Hockey team)

The last example is a proper noun(-phrase) and wouldn't necessarily follow the "standard" pluralization rules anyway. If you think about it you're not making "Leaf" plural you're making the noun-phrase "Maple Leaf" plural, and who knows what rules apply then.

Re: API Half-lives

#28

Post by wslh »

mechanical_fish wrote: post #3

It is indeed vitally important to remember that external APIs are unreliable and temporary. The question to ask in any given situation, though, is: How much more reliable and permanent is the code you own and manage yourself? And at what cost? However high the odds are that the founders of a given startup will leave their company within five years, the odds that the people who built your in-house widget will leave yo…

"How much more reliable and permanent is the code you own and manage yourself?"

Even with the worst bugs I can use and reverse engineer the oldest API if it runs on my own hardware. I can turn on and access my Amiga 500, or my Apple II "APIs". There are uncountable companies running legacy software, just sometimes they need to reboot the machines or "play" a known trick to continue working.

Re: API Half-lives

#29

Post by perigrin »

SimHacker wrote: post #16

Speaking of software half-lives: "Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. Basically, a lot of the problems that computing has had in the last 25 years comes from systems where the designers were trying to fix some short-term thing and didn’t think about whether the idea would scale if it were adopted. There should be a half-life on software so old…

As I pointed out on Gabriel's blog. This quote is six (6) years old at this point. Even if it was arguably relevant at the time (Alan Kay giving witness to an internal transition period in the Perl community), I'm not sure how it's relevant now.

Without specifics on which ideas Perl has that you feel don't scale, and how ... this is merely trolling by appeal to authority.

Re: API Half-lives

#30

Post by rue »

mechanical_fish wrote: post #15
jimbobimbo wrote: post #11

Earlier quoted context omitted.

Now, what your instinct says about viability of business that is built on top of "half-assed hack"? Or we'll just stick with the business model where there's VC or an angel with extra cash to burn, while we're making sure our instincts are happy?

I'm not sure I'm reading your sentence correctly, but the scary truth is that many, many brand-new businesses are initially built on top of half-assed hacks. By design! That's what all this "minimum viable product" talk is about. The canonical example might be Twitter. There's absolutely no question that their initial Rails-based infrastructure was not up to the task of running Twitter. But it was up to the task of r…

> But it was up to the task of running Twitter for a few thousand users, […]

(Tens of thousands, actually, perhaps hundreds?)

Post reply on HN