A list of public JSON APIs for use in web development(github.com)
github.com
A list of public JSON APIs for use in web development
https://github.com/toddmotto/public-apis
24 comments
Maybe I am missing something, but how does this differ from www.programmableweb.com? Seems more complete and more used
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
- 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
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.
- 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.
Another list of APIs:
https://github.com/abhishekbanthia/Public-APIs
https://github.com/abhishekbanthia/Public-APIs
This is great, next time I feel the urge for a side project I know which page to start on.
I'm disappointed nobody's made a public version of this yet: 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.
I'd use the demo server, but its youtube-dl is out of date, and it just feels wrong.
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
just out of curiosity people make public/free API: for profit and/or fun?
I (and others [edit just want to emphasise that I was part of a team, reading this back later sounded like I was saying a few people chipped in rather than a whole team all worked on it full time]) built GRID: https://grid.ac
Each page is machine readable: https://grid.ac/institutes/grid.5335.0 -> https://grid.ac/institutes/grid.5335.0.json (other formats work too, like nt for triples, and accept headers can be used instead but I can't make those into a link).
So if you count that as an API, we offer it because the whole project is about getting people to use persistent identifiers for research institutes and using that in their workflows. Free an public data is required for this to work well, and making it easier to hook into your processing is vital.
Selfishly, if people used persistent IDs more then my job and the work my company does would be significantly easier, so giving people a free way of doing this and making it as easy as possible for them helps move the field I'm in forwards. Also, when we have grid ids in our data outputs, we want people to be able to use them & get extra metadata. Making our own products easier to use & integrate adds value as well.
Edit - you can see others using the ids here:
http://www.bookmetrix.com/detail/book/2062f9b3-4e4f-4f00-b79... under affiliations
They're in the Altmetric top 100 lists https://www.altmetric.com/top100/2016
Linked up in scigraph: https://github.com/springernature/scigraph/wiki
It's used in wizdom.ai's visualisations https://wizdom.ai/public/analysis/brexit/dashboard?chromeles...
They pop up elsewhere too, but those I knew I had the links to handy.
Each page is machine readable: https://grid.ac/institutes/grid.5335.0 -> https://grid.ac/institutes/grid.5335.0.json (other formats work too, like nt for triples, and accept headers can be used instead but I can't make those into a link).
So if you count that as an API, we offer it because the whole project is about getting people to use persistent identifiers for research institutes and using that in their workflows. Free an public data is required for this to work well, and making it easier to hook into your processing is vital.
Selfishly, if people used persistent IDs more then my job and the work my company does would be significantly easier, so giving people a free way of doing this and making it as easy as possible for them helps move the field I'm in forwards. Also, when we have grid ids in our data outputs, we want people to be able to use them & get extra metadata. Making our own products easier to use & integrate adds value as well.
Edit - you can see others using the ids here:
http://www.bookmetrix.com/detail/book/2062f9b3-4e4f-4f00-b79... under affiliations
They're in the Altmetric top 100 lists https://www.altmetric.com/top100/2016
Linked up in scigraph: https://github.com/springernature/scigraph/wiki
It's used in wizdom.ai's visualisations https://wizdom.ai/public/analysis/brexit/dashboard?chromeles...
They pop up elsewhere too, but those I knew I had the links to handy.
I think it's great.
People collect much stranger things than public APIs :)
People collect much stranger things than public APIs :)
Ok, I have to say it, before someone else does :)
Someone needs to make an open API to query a list of open APIs
Someone needs to make an open API to query a list of open APIs
Jokes aside, you might have something there. More or less a list building service with a simple API for (public) access to that list.
At the very least, lists like this should be maintained in json. Worst case, you just pull for an update and the wrap that in whatever you want.
And for the repo just use gh-pages to display the json in some human-friendly format.
I've always want to build a Quora-esque app for public lists. For example, you could ask a question, "What are the top things I need to know about X?" Other users can post answers, as well as up vote and down vote. But something KISS. Not long full answers (a la Quora) but short and ideally with a link. So a list of high quality links in response to some question/need.
At the very least, lists like this should be maintained in json. Worst case, you just pull for an update and the wrap that in whatever you want.
And for the repo just use gh-pages to display the json in some human-friendly format.
I've always want to build a Quora-esque app for public lists. For example, you could ask a question, "What are the top things I need to know about X?" Other users can post answers, as well as up vote and down vote. But something KISS. Not long full answers (a la Quora) but short and ideally with a link. So a list of high quality links in response to some question/need.
The APIs.guru [0] API sounds exactly like you want.
[0] https://apis.guru/api-doc/
[0] https://apis.guru/api-doc/
Yes that definitely qualifies. Thank you for sharing.
Are you talking about google discovery api? ;) https://developers.google.com/discovery/
also as soon as you have a base that establishes you as resource other people will add the rest via pullrequests
Make lists or make APIs?
You sir get my github star of the week award. Much thanks
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 [email protected] or you can write to me directly by writing to [email protected].
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 [email protected] or you can write to me directly by writing to [email protected].
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
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
[0] - https://docs.google.com/document/d/15gwppUMLp0s1OhbzFZvFSeTb...