
A list of public JSON APIs for use in web development - happy-go-lucky
https://github.com/toddmotto/public-apis
======
sAbakumoff
some time ago I enjoyed using coursera API[0] for building apps for
educational purposes, the idea was something like "oh here is a new
interesting JS framework, let's build the coursera viewer with it". the api
doesn't require any consumer keys or auth to be applied, it provides the
meaningful data, thus it was so appealing to me.

[0] -
[https://docs.google.com/document/d/15gwppUMLp0s1OhbzFZvFSeTb...](https://docs.google.com/document/d/15gwppUMLp0s1OhbzFZvFSeTbvFkRfSFIkiIKrEP6cUA/edit#heading=h.wpqp7pmo0g4y)

------
Fragoel2
Maybe I am missing something, but how does this differ from
www.programmableweb.com? Seems more complete and more used

~~~
TeMPOraL
Compared to a Github list, Programmable Web

\- is ad ridden,

\- tracks the bejeezus out of you,

\- looks a bit sketchy in some places,

\- has a lot of junk you have to wade through before getting to the
interesting part,

\- and of course is not community-driven the way a Github list is.

On the other hand, when they do have a summary - see e.g. some API I picked up
at random[0] - it's _significantly better_ and more useful than what is on the
Github list.

\--

[0] -
[https://www.programmableweb.com/api/nationbuilder](https://www.programmableweb.com/api/nationbuilder)

~~~
TeMPOraL
Too late to edit now, but I feel that the criticism of PW I presented here is
pretty unfair to the site - especially that I meant the post to be more of a
comparison than evaluation. A better list would look like:

\- has plenty of ads (vs. no ads on GitHub),

\- tracks the bejeezus out of you,

\- the site itself looks more like a news site than catalogue (possibly
because it _is_ also a news site about APIs),

\- it's not so community driven compared to a GitHub list (OTOH, it seems much
more organized),

\- it's heavy (resource-wise) compared to GitHub,

\- _but_ , it has much better summaries of APIs and links to plenty of related
resources for each,

\- _and_ it has much more APIs than the Github list.

So please don't be discouraged by my comments; if you're into APIs, check the
PW site out and form your own opinion.

------
styfle
Another list of APIs:

[https://github.com/abhishekbanthia/Public-
APIs](https://github.com/abhishekbanthia/Public-APIs)

------
iDemonix
This is great, next time I feel the urge for a side project I know which page
to start on.

------
popman
I'm disappointed nobody's made a public version of this yet:
[https://github.com/jaimeMF/youtube-dl-api-
server](https://github.com/jaimeMF/youtube-dl-api-server)

I'd use the demo server, but its youtube-dl is out of date, and it just feels
wrong.

------
nickcoury
I just built out an Alexa skill using one of these! Great source for ideas
when you don't know where to start. Open sourced on GitHub.

[https://github.com/nickcoury/alexa-adopt-a-
pet](https://github.com/nickcoury/alexa-adopt-a-pet)

------
cooervo
just out of curiosity people make public/free API: for profit and/or fun?

~~~
brad0
I think it's great.

People collect much stranger things than public APIs :)

~~~
blensor
Ok, I have to say it, before someone else does :)

Someone needs to make an open API to query a list of open APIs

~~~
Meic
The APIs.guru [0] API sounds exactly like you want.

[0] [https://apis.guru/api-doc/](https://apis.guru/api-doc/)

~~~
blensor
Yes that definitely qualifies. Thank you for sharing.

------
thedatamonger
You sir get my github star of the week award. Much thanks

------
dberlind
Hi all, I was on vacation when this thread popped-up and I'm now just reading
through it all and wanted to say that we at ProgrammableWeb strive to be the
very best resource for anyone that's searching for APIs to use in their apps.
I'll be the first one to say that achieving this objective always presents a
challenge as there are many things we'd like to do by tomorrow, but not the
unlimited resources I wish I had to make everything (including your
suggestions) happen so fast.

Just to be clear, we have recently re-engineered our underlying data model to
better reflect the complex state of the API economy. That data model is really
at the foundation of all the functionality that our site offers. So, nailing
that model has been critically important. For example, many (not all)
developers love SDKs and these days, a large percentage of APIs ship with a
full complement of SDKs. Our data model makes it easy to go from one to the
other. If you land on an API, you can find all the related SDKs (even if they
are third party SDKs that don't come from the API provider). If you land on an
SDK, you can quickly get back to the "parent" API. I know.. not a big deal...
the sort of basic task that MySQL and other RDBMS are made for. But you'd be
surprised how, once we enabled this obvious capability, users started to move
back and forth between them. There are many more not-so-obvious capabilities
that taken together, will result in not only a very robust power search
capability (ie: I'll take RESTful Storage APIs that aggregate all the other
storage APIs - dropbox, gdrive, box, etc. -- and offer CSV, XML, and JSON-
formatted responses), but also a much more powerful alerting service (our most
popular feature).

That data model also had to be nailed to enable a great API for APIs which is
also on our road map. I could go on, but hopefully, you get the point. We
absolutely hear you on the many things we can do better.

Finally, I would like to address the part about ads, tracking, and so forth.
Yes, we do have ads. To build our technology, to run a research team that's
constantly finding the latest APIs and SDKs and adding them to our directory,
etc, we need sources of funding. We have worked hard to ensure that the ads
are not what you're seeing elsewhere on the Web.. you know the ones that have
pop-ups on top of pop-ups and auto-playing video on top of already playing
video content and so on. Our pages are not littered with text ads either. I
would love to run a site without ads at all. But knowing that this isn't
possible, I hope that you would consider the minimally invasive ad environment
as one that isn't following the rest of the pack to do anything to keep you
from your task of searching for APIs or reading our great content.

And regarding tracking, I suspect that it's mostly connected with the ads and
retargeting (again, both necessities to help subsidize the cost of us running
the site). And we use Google Analytics for measuring traffic which may trigger
tracking detectors. But we (ProgrammableWeb) are not deliberately tracking you
with some nefarious intent. We do very basic stuff like looking to see if
people are finding their way from APIs to SDKs and back again to ensure the
usability of our site.

We welcome feedback on everything that we're doing and have an open door
policy. You can write to the entire team by writing to
editor@programmableweb.com or you can write to me directly by writing to
david.berlind@programmableweb.com.

------
joop_nl
API’s have become essential components in applications to utilize third party
services and data resources. In a perfect world the integration between a web
API and a deployed application works without any issues, but we all know this
is never the case. I’m actually currently investigating what causes problems
related to API integration and what we can do to mitigate these. Best practice
guides are nice, but they can only do so much.

Ever used a web API and ran into production problems? You can help out by
taking this survey:
[https://www.surveygizmo.com/s3/3708659/4963a5d97d3e](https://www.surveygizmo.com/s3/3708659/4963a5d97d3e)

