Show HN: APIRank.dev – We crawled and ranked public APIs from the internet (opens in new tab)

On a more serious note, if the purpose is to be able to compare candidate APIs that you're looking at using, here are some features that I think might be helpful:

* Tagging, and filtering based on those tags. Example: "Show me APIs that deal with SMS"

* Select two or more APIs for direct comparison. Example: "Compare Twilio, CleverTap, and Amazon SES"

* Sorting by column heading. Example: "Sort by median response time, descending"

Also, I can't quite get the search to work for me. The term "Paul" returns the top entry ("P J S Paul Ministries API") and one other ("PoGoSnap API") that doesn't include the search term. "Twilio" returns no results, even though there are three entries on the bottom of the first page that start with that string.

A well designed API with no OpenAPI support or 3.1.x spec support will get a poor design score.

I think user generated content might be the way to go for Design. Let people score and review the design quality.

Apple Itunes : https://developer.apple.com/library/archive/documentation/Au...

last fm : https://www.last.fm/api

acoustid : https://acoustid.org/webservice

spotify : https://developer.spotify.com/documentation/web-api/

discogs : https://www.discogs.com/developers

deezer : https://developers.deezer.com/login?redirect=/api

music brainz : https://musicbrainz.org/doc/MusicBrainz_API

gracenote : https://developer.tmsapi.com/Sample_Code

---

Additionally, why not list API rate limits?

Or some lookups don't need any security, like querying Apple Itunes does not require anything except for being nice and rate limiting.

Say service A has an API:

- GET /users/<id> - 100ms

Service B has multiple APIs:

- GET /users/<id> - 100ms

- GET /users - 250ms

- GET / - 500ms

Which service is faster according to your algorithms?

I'm also a bit skeptical of your other metrics. "P J S Paul Ministries API" is 5/5 in popularity while Adyen is 3/5?

A sample response takes this form: `{ type: 'data', nodes: [ { type: 'data', data: [Array], uses: [Object] }, ... ] }`

Things get a little strange (for me at least!) when I start poking around in the data array. At index 0 in this array is an object with some information on what I think is mostly just paging and the length of the data array (sans this first element). At index 1 is an array filled with numbers that correspond to array indices in the initial data array, and the objects at those specified indices are the actual data sources. While the keys in those objects are actual descriptors of relevant information, the VALUES for those keys are also array indices. Essentially the incoming data structure is a super flattened array with some objects/ additional arrays that just point to other indices in the data array.[1]

Is there a name for this type of pattern? Is it just an artifact of using some query library to handle data fetching? Apologies for the naivety, I still consider myself a fairly new dev (especially when I see something like this!).

[1] More complete example (not sure if I explained this well):

  {
    type: 'data',  
    data: [  
      { endpoints: 1, count: 3971, currentPage: 5 },
      [2,221,355,...], // at array index 2 we should expect an object
      { id: 3, commentsRatio: 4, owaspIssues: 6, ... }, // array index 2: object with values that are all indices in the original data array that hold the actual values!
      ...
    ]
  }

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?

Given generic external scanners propensity for giving false positives, I'm very skeptical.

In order for this to have any use, it seems to me you'd need to at least group the API's by use case/product type.

Similarly: how can you meaningfully measure the performance, security, or reliability of these APIs without first determining whether you're communicating meaningfully with them? I assume that many (most?) of these APIs require some kind of credential; it's hard to glean anything of interest from a server's ability to reliably send an error message,

Is the plan to actually build this out to be a usable tool or is it just a way for you to get people to submit API:s and get some marketing?

I also think there's way more metadata that could be useful in ranking. Things like API documentation, communities, usage cost, complexity of API, statefulness, age of the API...

Anyway, looks like a cool project that will be useful to some people

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.

Looking forward to some more browsing on your site.