Monday, May 09, 2011

Google APIs Discovery Service: one API to find them all

Anton
Monsur
Joe
By Anton Lopyrev, Monsur Hossain, and Joe Gregorio, Google Developer Team

As announced at last Google I/O, the new family of Google APIs client libraries runs on top of a brand new API infrastructure, which allows Google to reduce the amount of work needed to release and maintain the client libraries. This is done through a simple API that provides machine readable descriptions of Google APIs that the client libraries take advantage of.

Today, we are announcing the Google APIs Discovery Service, which is the secret sauce behind the new client libraries. This service exposes machine readable metadata about Google APIs including:
  • A directory of supported APIs.
  • A "Discovery document" for each of the supported APIs that includes:
    • A list of API resource schemas based on JSON Schema.
    • A list of API methods and available parameters for each method.
    • A list of available OAuth 2.0 scopes.
  • Inline documentation of methods, parameters, and available parameter values.
The service is accessible through a lightweight JSON-based API. Navigate your browser to https://www.googleapis.com/discovery/v1/apis to get a quick look at the available data.

You can use the APIs Discovery Service to build tools for interacting with Google APIs, such as IDE Plugins and client libraries. We use the service at Google to build a number of such tools:
With the launch of this service, we are also open-sourcing the code for the APIs Explorer, which can serve as a great example of how to use the service.

Read more about Google APIs Discovery Service in the documentation, or explore its API in the APIs Explorer. If you are attending this year’s Google I/O and you want to know more about the service, make sure to attend our session “Building Custom Client Libraries for Google APIs” where you can chat with the developers of the service face-to-face.

We look forward to seeing what sorts of things you can build. Let us know of any issues and feature requests in our developer forum. Happy hacking!


Anton Lopyrev is an Associate Product Manager for Google APIs Infrastructure, previously a software engineer on Street View. He is a computer graphics enthusiast who is also passionate about product design.

Joe Gregorio is a Software Engineer. In the past four years at Google he’s worked on APIs, Google App Engine, Google Wave, and now has come full circle and is back working on APIs.

Monsur Hossain is a Software Engineer for Google APIs Infrastructure and enjoys making it easier to use APIs.


Posted by Scott Knaster, Editor

12 comments:

  1. This is so insanely ultimate.

    ReplyDelete
  2. If you created an API of APIs that do not contain themselves, would it contain itself?

    ReplyDelete
  3. Awesome to the power of rad.

    ReplyDelete
  4. Great work, this is so valuable!!! Awesome!

    ReplyDelete
  5. Love the title... has a familiar RING to it.

    ReplyDelete
  6. a api to find all other apis,great!!!

    ReplyDelete
  7. you basically re-invented how UDDI sits on top of WSDL?

    ReplyDelete
  8. I never get these kind of APIs, what can you do with it?

    ReplyDelete
  9. Sorry, but this just springs to mind

    "One Ring to rule them all, One Ring to find them,
    One Ring to bring them all and in the darkness bind them"

    ReplyDelete
  10. It would be nice to see followup to the OP - surely there's updated info in the 6months since. My specific question relates to the inclusion or exclusion of products in the Explorers list. Orkut's there by GMail isn't? If my intent is to interact (CRUD) with Google Contact objects, what library am I do use? This post leads one to think the original .NET Lib is being deprecated in favor of this.

    And yet, seems no direct access to GMail or Contacts.

    ReplyDelete