4 ms·

APIs that developers should know about

55 points by johns 16y ago

mickdarling 16y 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 16y ago
More great ones: cloudmailin, uploadjuicer, recurly, pusherapp
- chime 16y 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/ https://www.tropo.com/ to your list.
- mike-cardwell 16y 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 16y ago
An API that I found useful: http://www.wordnik.com/developers http://www.wordnik.com/developers
- mike-cardwell 16y 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 16y 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-cardwell 16y 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 16y 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...
    - mike-cardwell 16y ago
      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...
robles 16y 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.

55 points by johns 16y 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 16y ago

More great ones: cloudmailin, uploadjuicer, recurly, pusherapp

chime 16y 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/ https://www.tropo.com/ to your list.
mike-cardwell 16y 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 16y ago

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

mike-cardwell 16y 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 16y 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-cardwell 16y 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 16y 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...
  - mike-cardwell 16y ago
    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...

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