Skip to content
kdykes edited this page Nov 30, 2012 · 30 revisions

A Saner (and Geekier!) Approach to Working with APIs

What is this?

Working with APIs can be a nuisance, because you have to

  • study the API documentation (often complex, or poorly written)
  • find and evaluate available libraries for using the API
  • write code that couples your application with the API -- or define an abstraction layer
  • worry about the performance impact of making synchronous API calls -- or put in place a framework for background jobs
  • decide how to handle errors

We make all of this easier. Geekier provides

  • machine-readable API descriptions, created by experts and organized around how to use these APIs to get things done
  • a simple abstraction layer to use in your code, avoiding vendor lock-in and providing lots of flexibility
  • a service framework that actually makes API calls
  • easily customized hooks for logging, retry policies, error reporting, and analytics

How does this work?

API descriptions

Our API descriptions are based on SPORE's syntax, with some extensions inspired by WADL plus things we've learned from building rules.io. The descriptions include information about

  • HTTP info (e.g., path, method)
  • whether authentication is needed, and how it is done (e.g., oauth)
  • expected errors
  • required and optional parameters
  • valid parameter types (e.g., integer, string)
  • valid parameter values (e.g., 'html', 'text')

Our extensions make it possible to build user-friendly interfaces for specifying API calls, without knowing in advance which APIs might be involved. For example, a monitoring application might want to include a form for setting up alerts. Rather than offering a limited choice of email or SMS, for example, the application could allow the alert to be sent via any of the Geekier APIs, and use the info in the API descriptions to build a fully functional user interface, including validations.

API connection factory

At the heart of the Geekier implementation is a factory that builds API connection objects for talking to any of the described APIs. One way to use Geekier is to use this factory in your application.

Geekier as a service

In most cases, a better way to use Geekier is to use our simple event-based abstraction layer in your application. The Geekier Service will consume this event stream and make API calls for you in the background.

How can I help?

If you believe that an interoperable web needs an open framework for connecting applications and services based on self-describing APIs, join us!

Extending the reach of Geekier benefits the entire community. You can do this by contributing new API descriptions, or libraries making Geekier accessible from other programming languages (so far we've got Ruby covered). Email us at [email protected] if you'd like to get involved.

Other info

Sample description

Clone this wiki locally