APIs that developers should know about

http://econsultancy.com/us/blog/6963-five-apis-developers-should-know-about

by johns • 16 years ago

55 17 16 years ago

Saplo looks to be a good resource for my new twitter app so we don't have to build all our own in-house tools to duplicate pretty much what it looks like they are doing.

I signed up to get access to the API's there, but does anyone on here have experience using them?

railsjedi• 16 years ago

More great ones: cloudmailin, uploadjuicer, recurly, pusherapp

chime• 16 years ago

Cloudmailin is exactly what I was looking for the other day. Perfect way for me to write a simple Tropo app that calls (not texts) me when a server fails and leaves me a voicemail with the error. Oh and add https://www.tropo.com/ to your list.

mike-cardwell4• 16 years ago

I could do what cloudmailin does with ~6 lines of Perl and a procmail recipe...

Uploadjuicer can be replaced with imagemagick. Should be less than a days work to write a web service if you really need one. Host on AWS and bring up more nodes if you need to process more images than one node can handle.

Recurly looks like it offers real value. I would use Recurly, but with the intention of replacing it with my own custom system after a while.

Pusherapp - Trivial to replicate in house. Their front page also refers to browsers which don't support WebSockets as "crap"

JoshCole• 16 years ago

An API that I found useful: http://www.wordnik.com/developers

mike-cardwell4• 16 years ago

This is just a thesaurus... It doesn't need to be a web service. You can download a thesaurus and query it directly.

Figs• 16 years ago

Building software on top of someone else's web api is a really, really bad idea. If you don't control the system it runs on, then you are completely at the mercy of someone else's business. If they go broke, your software goes down. If they have a technical problem, your software goes down. If they decide to change some aspect of their software, your software goes down. Please, think twice before you build your businesses out of this deck of cards.

mike-cardwell4• 16 years ago

Absolutely. Of the 5 services mentioned:

- Zencoder - I'd use these to minimise costs at the beginning, but I'd build my own system along side it and replace Zencoder with that system once I started to earn.

- Twilio - Spend the time you'd use learning Twilio to learn how to configure up Asterisk instead. Set it up with multiple SIP providers with multiple PSTN gateways.

- Saplo - I'm not familiar with these guys and it's not fully clear what they do to me.

- Adaptive Payments - Paypal? You're kidding right. Don't use Paypal. If you absolutely must use them, make sure you have a drop in replacement for when they fuck you over.

- SimpleGeo - No need to use a web service for this. You can get IP to geo data for free nowadays, and every programming language has a library for it.

toumhi• 16 years ago

Why would you duplicate what other people have built before you? Everything that has been done correctly by others, you should use. Learning how to configure Asterisk and how to use Twilio doesn't nearly require the same amount of time.

I agree to some extent that you should not rely on other services without having any kind of replacement, but to say that you have to build everything yourself seems rather ill-informed advice...

ryanelkins• 16 years ago

Many developers have the initial gut reaction to build instead of buy. I've found that many people don't really fully understand the ramifications though. Even if some of these places only have 3-5 developers working on this full time - that's still probably FAR more resources than another company, especially a startup, can devote to the problem. You also now need resources to maintain and update it. All of this takes resources away from whatever it is your business actually does.

I guess the hard part is really determining what is trivial vs what is worth letting someone else take over. Some people may look at the above services and feel like they look pretty easy - and then a week or a month down the line they realize there is more to it than they first thought.

Other aspects people often don't think about - dashboards and admin sections usable by a non-developer.

I'm not vouching for any of these services as I have never needed to use any of them, but I would definitely guard against blind "not invented here" syndrome.

_pius2• 16 years ago

Of course I agree with the idea that integrating with an API can make your software more fragile (it's a truism), but you greatly understate the costs of Not Invented Here syndrome.

To a few of your points:

- Twilio - Spend the time you'd use learning Twilio to learn how to configure up Asterisk instead. Set it up with multiple SIP providers with multiple PSTN gateways.

Seriously? The idea that going from zero to production on Asterisk takes roughly the same time as doing it with Twilio is risible.

- SimpleGeo - No need to use a web service for this. You can get IP to geo data for free nowadays, and every programming language has a library for it.

Again, preposterous. That's not what SimpleGeo does, even the briefest look at the homepage shows that: http://simplegeo.com/

_pius2• 16 years ago

All good points except for the first sentence. :)

The thing is, if you're building a startup, you want to deliver value to your customers as quickly as possible ... you know, so you don't die.

Customers don't care whether you used an API or rolled the functionality yourself. For an early stage startup, implementing or troubleshooting back-end functionality you could have outsourced to an API is, to a first approximation, a waste of time.

noodle• 16 years ago

If you don't control the system it runs on, then you are completely at the mercy of someone else's business. If they go broke, your software goes down.

but, couldn't you make this argument about many things? your company's payment gateway? your bank? ISP? server host? etc.. your business will hit the breaks if there are any major hiccups with the providers of any of these services.

i mean, its contextual, of course. if you've written a twitter app, its different. its not an app being built with the help of an api, its an app being built specifically for an api. but a single business makes use of lots of services, and an api is just a service.

robles• 16 years ago

Figs,

I wrote this article. I think it's more accurate to say "Building software on top of someone else's web api can be a really, really bad idea" -- if you don't do due diligence. I've written about the perils of building on top of consumer web platforms in the past, and personally think there's far more risk in building apps for, say, Facebook and Twitter, than incorporating into your own product a commercial API that you've vetted reasonably well.

Developers/entrepreneurs need to be pragmatic. New ventures that spend all their time and money trying to eliminate risk usually fail; the ones that succeed instead try to manage it. When working to get something to market to see if it will fly, it can be a huge mistake to invest in building low-level functionality from scratch. Most developers/entrepreneurs, for instance, aren't going to build their own video encoding engine. Sure you could use ffmpeg, but out of the box ffmpeg is hardly Zencoder. The time, cost and functionality advantages of Zencoder certainly outweigh whatever risk there is that Zencoder would go out of business in the near term.

In short, it's about cost and time-to-market. Reinventing the wheel usually increases both. So unless you have unlimited resources and already have a strong presence in a market, it's far better to bring a lot of this stuff in-house after you've validated that there's a market for your product and it's making some money.

APIs that developers should know about

Related Stories