Skip to content

API Discovery on the Public Internet

Jump to bottom Edit New page
Steven Willmott edited this page Jul 30, 2014 · 7 revisions

Convener

Steven Willmott (@njyx)

Attendees

Many - please add your names to the Wiki!

Notes

  • Google search is probably the most popular way of finding APIs right now.

  • Another is git search - people looking for Swagger/Blueprint on Github

  • Also Mashape, Programmableweb, tagging is sometimes not very helpful on ProgrammableWeb.

  • Also, finding an API is often oriented around - finding the company (e.g. sentiment analysis): and then seeing if they have an API.

  • Track record matters on APIs - there's often no way to tell how good an API is when you find it.

  • Maybe we need something like API Match.com! See http://api500.com/ for someone working on this.

  • Something like NPM would be useful: API owners push updates, submit. last updated and used info is valuable.

  • One valid question - do we need anything other than Google? Since we are not doing anything automated right now developers are always in the loop anyway. Steve responded: 2 important reasons: 1) not clear google rank on web pages corresponds to good APIs, 2) as the number of APIs grows we do want to automate and no simple meta-data to pull in programmatically means that'll be very hard.

  • Are Internal v’s external problems different? Internal API launches (majority in the group):

  • On Internal need to coral all the APIs, do brown bag lunches when one launches, but it can be hard to keep the overview.

  • On External, sometimes you actually don't want a lot of attention at the beginning (crap, our dev portal is listed on Google!).

  • Microsoft internal for example - 100s of APIs, portal documentation is the key to finding them, if they are not linked in any dev-area, no chance to find them.

  • Federal government APIs - Kin Lane working to create APIs.json specs.

  • Current Public API launch steps:

  • Publish

  • Look at media coverage

  • List on ProgrammableWeb

  • Potential hackathon participation

  • Two solution architectures for big public discovery:

  1. Active registry with APIs automatically pushing changes when there is an update (like Ruby Gems).
  2. Meta data and search. (Providers publish standard meta-data and anybody can write a search engine).
  • APIs.json (http://www.apisjson.org/ and http://www.apis.io) is an example of the second approach - question is, how can we scale either to break the critical mass problem.
  • Makes sense to try multiple approaches.
  • You need some mechanisms to do all the aggregation because otherwise providers have no value in publishing the data or pushing updates:
    • could be a directory.
    • could be a search engine.
  • We need to break the cycle of no data.
  • APIs.json could work like robots.txt.
  • The good news is thatpeople need API adoption when they launch, and there are people who are paid to do this - so if there is benefit to a mechanism, people will start to do it as best practice.
  • Spam could be a real problem with public open discovery systems - but maybe this just needs to be dealt with over time.
  • Another interesting area is what value can be added on top once the APIs are discovered - e.g. gauging activity, fitness of the API - Kin Lane does this on the APIs he monitors.
  • We didn’t do machine readable descriptions for a long time, docs were the driver, now there are many uses.
  • Fans should be able to do it.
  • Where is the format at? APIs.Json now on v. 0.14, pretty stable and now with JSON schema - people can give it a try and give feedback!
  • Extensibility is important for internal use and enterprise.

Some takeaways:

  • For APIs.JSON, if you're interested:
  • Comment on the format - see the google group linked from here http://www.apisjson.org/
  • Consider deploying a file for your API and registering on http://www.apis.io/ so we can figure out if it's working.
  • Also http://www.apis.io has an API to get all the current apis.json files it knows about and is open source. Bootstrap your own search engine.
  • General:
  • This is a hard chicken and egg problem.
  • We do need to solve it, if we ever want to to people to guild good maps of all the APIs out there
  • Different approaches can work - directories, meta-data, search - a few have to be tried - we need to find at least one which scales

Additional Considerations (added later)

  • Anyone in attendance please add!
Add a custom footer
Add a custom sidebar
Clone this wiki locally