

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

======
Figs
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-cardwell
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
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...

~~~
mike-cardwell
Given the choice between spending a day or a weekend building something in
house, or using a remote web service, I will always bring it in house. Because
it's ridiculous to rely on some remote service if you don't have to.

If it will take me a couple of months to replicate something which already
exists as a web service, I will usually use the web service. If only
temporarily.

None of the web services mentioned so far on this page seem significantly
difficult to replace, and suggesting that people use them seems rather ill-
informed advice...

~~~
techiferous
I think it matters whether your business has found product/market fit. Before
product/market fit, taking the time to build things in house increases risk--
risk that you're wasting your time on a product no one wants. After
product/market fit, it reduces risk--risk that your product that people are
paying for will have reliability problems.

------
robles
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.

------
mickdarling
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
More great ones: cloudmailin, uploadjuicer, recurly, pusherapp

~~~
chime
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.

------
JoshCole
An API that I found useful: <http://www.wordnik.com/developers>

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

