Show HN: APIRank.dev – We crawled and ranked public APIs from the internet

A christian ministry's API is ranked higher than Coinbase? You guys are nuts.

This. As soon as you see "number of vulnerabilities it contains", you know it's bullshit. If it were that easy to spot legitimate bugs, the authors would mostly already have fixed them. Without human verification, probably somewhere between 950 and 995 out of 1000 detections are bogus. Also OWASP has become such a meaningless buzzword, as if it's the only web bugs that matter, or as if it's a well-defined set with clear boundaries, let alone testable things (direct object reference / missing authorisation, good luck defining a rule for that, in general but especially with public APIs). (My employer is getting more corporate and guilty of this as well nowadays: trying to please buzzword-scanning customers by bringing up OWASP Top Ten in every web report no matter how relevant.)

I clicked because I was indeed curious how they'd rank, but this being the first point tells me that no sensible ranking could be found

The only objective metric in the set is response time, but anyone would agree that this isn't the only thing you use to select what api to use

> During a YC meetup I spoke with a fellow founder that told me how hard it was to pick the right external APIs to use within your own projects. I realized that most of what we build relies on public APIs from external vendors

I have a habit of sleeping under rocks but why do people do this? It seems incredibly brittle and strictly worse than leftpad-esque dependency hell – you can’t freeze or fork an API.

I can understand that for payments, maps or even email sending it’s more convenient, but that’s at least a bounded issue.

Are the apps we are building today gonna work in 3 years without meticulous maintenance? Are we doomed to suffer flaky experiences from compound latencies and rate limiting? And what’s the point of your 5 nines if you rely on third parties anyway?

I've been having this fight recently at work.

We're implementing a new (cloud) platform that's pretty central to our primary business. Some sub-projects have already spun off, before we had even decided how to set up and maintain the platform, because I said to meet the timeline we need to focus on more broad, general integrations first.

The decision was, instead, to bring in additional developers whom several months later we're still helping learn the APIs and troubleshoot problems (amidst the rest of our integration tasks).

Meanwhile a few weeks ago, I finally got the go-ahead and a DBA's time to do the integration I wanted. We've got a live database of 90-some tables dumped from the platform, including everything these projects are fetching (but with a greater delay between updates), accessible to the entire org. Reporting teams and business analyst are already writing queries to drive the services they need, freeing up our developers to work on other tasks.

A good API can provide very rapid, very specialized development; which is great when that development _is_ your business and so you're paying developers to keep up with it, or it's not so important that is kept up on (personal projects, prototypes, and temporary services). And a well designed and managed API shouldn't change _that_ much _that_ frequently.

But ignoring that an external API is always something you don't control and needs to be maintained is a costly mistake I've seen my org fall into over and over again.

Interested project.

But I worked on the Xero assets api, and I’m sad to say there was only one user. Maybe things have changed since I left, but I highly doubt it deserves a 4/5 ranking for popularity. I suspect 1 might now be more like 4 integrations now. But either way, it an irrelevant piece of product ecosystem. Every other API by Xero is more heavily used.