Public APIs is also a directory - you could now use the apis.json data to keep that directory info from getting stale. That's the point of the http://www.apisjson.org + search combination.
We almost need the inverse: APIs that are showing signs of death ala Netflix. It's usually the case that you have an idea for something and an API is pretty easy to find. Getting your integration pulled out under your feet is really what sucks.
I'm working on APIs.json collections of deprecated APIs, as well as working on APIs.json references to building blocks like pricing, and TOS...then allow for inverse searching for APIs that do not have pricing, or have TOS that are not friendly. The next project after API Commons is to take TOS Didn't Read work and incorporate as part of APIs.json, so that APIs.io will have this type of data to search by.
Still, it's a risk often worth taking. If you look at many of the hypergrowth projects, a lot of them rely on a current market adopting their product as a supplement to a platform.
It might be nice from a usability perspective to only show the error message once. As it stands now, it's possible to continually search for a non-existing API and fill the screen with red errors [1]. (Not that this is a particularly compelling or realistic workflow or even worth fixing. They disappear within a few seconds anyway, which is nice.)
I think this is a legitimate question. Personally, it would be cool to scan lists of API's for idea inspiration but this doesn't really provide that functionality. Now what would be cool here, is if the APIs returned here had docs presented on the website with a consistent UX/UI. But then you would need an API for an API :)
The apis.json format this looks for contains fields for formats like http://www.swagger.io/ which it could then pull in (or someone else could) to render the docs in line.
Main thing that's useful is that if it can pull in all the elements (def portal, specs, etc.) you get deeplinks to everything. Google also doesn't help finding some APIs easily since it just treats it as content or they aren't linked.
In the long run hopefully a lot of the fields in the apis.json files this pulls on will be machine readable (e.g. meta-data for things like major T&C provisions), pointers to libraries etc. so you could filter on that.
What I'd like to see, replace the "Documentation" link in each search engine result - with the apis json rendered to a standard template thusly http://jsbin.com/favajizuti/1/edit
I guess we'll see if people find it useful - the point of this is: there is current NO structured meta-data about APIs out on the web and that will be needed if we're one day goingto find APIs with all their associated elements as easily as we can web pages today.
Hence the format http://www.apisjson.org (it's basically sitemap for APIs) and the search engine http://www.apis.io. The search engine is also open source so you can run your own, format is completely open.
So if we (3scale) get some benefit I won't be unhappy - but if more people start posting API info then it'll benefit everyone.
It doesn't offer anything useful? Really? I spent almost 80 hours hand crafting the APIs.json for this release. I'm building federal gov versions of APIs.io with this to drive traffic to vital gov resources, and working to priortize the APIs.json + Swagger for vital non-profit resources ilke DPLA. WTF have you done notastartup to further the API community? eh? Links please!!
There's a couple of syntax errors, but it does eventually load. I think the whole screen is dependent on a web request completing.
Tip: try to get as much of it rendered as possible while you're waiting. Most JavaScript frameworks have the ability to manage sub-views of some sort, so you can get most of that screen in place. If you're waiting on the items to load, try greying out the search box or something?
I have no idea if there's a backend hug of death but the search function seems to do nothing at all when I try to search. Click search.. no loading icon, no loading text, nada
This reminds me of Bret Victor's "Future of programming" at http://vimeo.com/71278954 particularly at 13:50 about APIs - envisioning how computers could themselves discover available services at other computers. Maybe this API index is just the first step towards enabling computer programs to independently interact with each other.
I think a key here is hypermedia. APIs can only be machine-discoverable if there are hypermedia links pointing to them (which is how this helps). If there are no links, then some human must hardcode it.
This also is a reason for including hypermedia in your API, because really, being machine-discoverable is not just something that the API itself benefits from... each resource and state can benefit from included hypermedia as well.
I agree that hypermedia is a more optimal solution for API discovery. APIs.io + APIs.json + machine readable formats like Swagger will provide us with a bridge between what we have, and what we should have (aka hypermedia). We'd all love to have a perfect reality, but unfortunately we get the one we have. ;-)
Same. Alan Kay talked about this once, I have a paraphrase to hand:
"This current effort of doing term-based ontologies is a disaster. It requires too much agreement [...] I can't find anyone working on this notion of general negotiation between anything that can negotiate [...] Negotiating meaning is the problem of our time."
Bret Victor has influenced a lot of my thinking that has gone into APIs.json and API Commons, and the work I've done with EFF on the Oracle v Google case, and how we need to get APIs to the next step. Thanks for the observation.
Would be nice to have some general collection of libraries in various languages.
Hope we will there one day, but for now we have API Pages, that include middleware (like mini apps) to extend/modify one/various api.
It's search v's directory. The idea is you can post meta-data on an API on your own domain using a format http://www.apisjson.org/ that can then be crawled. Right now you still submit links, but it'll start crawling. So then anyone can write a search engine (the code for apis.io is open source).
With a directory like programmableweb it's useful but you need to put your data into the repository - and then remember to update it.
I'm getting the following error [1] every time I try to open the page with IE11 on Windows 8.1. It prevents bootstrap.js from loading, which then prevents everything else from working and just shows a blank white page.
Might explain why some people are having problems loading the site, though it works fine in Firefox for me.
If it helps, the debugger points to an invalid ʹ character in 01135560588655f631606d051ab4cd4df545eead.js. I circled the character in blue [1]. Beyond that I haven't the foggiest idea.
Is there a API search engine where one can enter sample inputs and outputs, and get a list of methods that return the outputs for the given inputs? Smalltalk has a search function like this - very handy instead of trying to guess method names.
Very cool. Would be great if you teamed up with Readme.io to make sure all of their customers are loaded into the search engine (our docs are with Readme)
Using the APIs.json format you can reference any machine readable format like Swagger. We are currently working on generating Swagger for each of the APIs currently listed. By February there will be Swagger for most of them listed.
