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
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.)
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.
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)
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 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
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!!
you sound like a pretty sad little dude to not want to help vets get healthcare. people find stuff in libraries. keep APIs from having copyright. checked out your little tech services you provide in BC. Good luck with that. I hope you get a positive client and change that little eeyore attitude you have.
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.
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.
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."
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. ;-)
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.
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.
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.
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.
92 comments
[ 0.26 ms ] story [ 151 ms ] threadTip: 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'm on chrome on mac and it doesn't seem to load even after about 5 minutes of just letting it do its thing.
Can we get a .api TLD so it can be http://apis.api/api/apis?
And maybe an HTTP protocol extension so it can be api://apis.api/api/apis?
[1] http://imgur.com/dqZY8zW
You can check static pages: http://apis.io/faq http://apis.io/lint http://apis.io/builder http://apis.io/apiDoc http://apis.io/about
Would be really awesome if the site could show api's documentation in a unified standard format
Kudos for this!
Stuff that makes it easier to use the actual underlying API.
Eg the YouTube Data API is nice, but you can save a ton of time if you use one of the client libraries:
https://developers.google.com/youtube/v3/libraries
https://www.apitools.com/apis/burning-man
EDIT: found it its http://www.mashape.com
is this related to icon font used in the app ? Font-awesome? You can check in your console and see if there a 404 on the corresponding file.
(http://www.programmableweb.com/apis/directory)
With a directory like programmableweb it's useful but you need to put your data into the repository - and then remember to update it.
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.
We have the previous version of APIs.io supported over here: https://apimatic.io/apientity/search
Let's connect this too!
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.
there are also some listed http://apis.io/?search=tag:voice
jq FTW
"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."
http://smalltalk.org.br/movies/
If you can't find it, you will at least find some other amazing material
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.
https://coinkite.com/static/api/apis.json
You could use http://apis.io/lint to validate your apis.json file.
Testing your file I found that properties are not correct
"properties": [ { "type": "X-Documentation", "url": "https://docs.coinkite.com" } ],
should work
also "photo" is not a valid parameter. And "vCard" is expecting a URL and can't be empty.
hope it helps