Content-Length: 5052 | pFad | https://developer.nrel.gov/api-case-study/

National Renewable Energy Laboratory API Case Study

Transitioning towards APIs to make data sharing easier

Summary

The National Renewable Energy Laboratory (NREL) has been sharing its data for many years. More recently, the demand for our data has increased, while at the same time there has been a shift in demand towards more dynamic requests and machine readable data. Much of this increased demand stems from developers and partners wanting to leverage our data to build their own applications and as input into their own analyses. To address these growing demands, we've begun to shift how we share data towards web service application programming interfaces (APIs). To address some of the challenges in building and exposing new APIs, we've developed a common platform to for all NREL APIs to leverage.

Challenge

Historically, NREL shared data using spreadsheets or static data dumps. However, as the demand increased and shifted towards dynamic requests, we realized our existing model of sharing data was not maintainable. It was difficult to ensure all our partners had the latest data at all times. It was onerous to work through the legal agreements necessary to share the data with individual clients. There was also a demand for our data in formats like JSON and XML.

To address these shifting demands we sought to expose more of our data through public web services. There was certain functionality we wanted standardized across all of our public APIs, such as common authentication and rate limiting, and we wanted to minimize the effort involved in implementing those features for new APIs.

Approach

We launched the NREL Developer Network in October 2011. Our main goal was to build an overarching platform that made it easier for the public to use our APIs and for NREL to produce more APIs.

To make it easier for the public to use our APIs we had two driving requirements:

  1. A single entry point: Our APIs belong to different projects and can be developed by different teams at NREL. This can be confusing to an outsider, so it was important to consolidate all our APIs in a single place to make it easier for developers to find and consume our APIs.
  2. A single license agreement: Previously, we would have to strike data sharing agreements with each individual interested in accessing our data. It was important to streamline this process so any user could easily access our public data by agreeing to a flexible and generic data use agreement.

In addition, we also wanted to make it easier for developers inside NREL to build more APIs and expose them publicly. We identified common functionality that should be present in all our public APIs and addressed those features in a shared platform. The following functionality is standardized across all APIs by our platform:

All of these details are handled by our platform, so new APIs don't have to concern themselves with this functionality and repeatedly implement the same functionality.

The platform we built to serve these needs has been open sourced as API Umbrella.

Results

Between the public launch of the NREL Developer Network in October, 2011 and November, 2012 we've seen the following usage:

In addition, NREL is currently developing 40 new web services for future release.

Resources









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: https://developer.nrel.gov/api-case-study/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy