Indeed, I couldn't agree more. API is a key element to foster data based innovation.
At OpenDataSoft (http://www.opendatasoft.com), we are building and operating a Cloud based data management platform. This platform is built "API first". It means that any feature that can be accessed from the portal is also available as an API call. And actually, the portal is itself the first consumer of the API. Available APIs include (see http://docs.opendatasoft.com/collection/1382-using-apis for more details):
- Dataset catalog APIs (keyword and facetted search of datasets within the catalog).
- Dataset APIs (search within dataset records, geo clustering of geo dataset records, numerical aggregations of dataset records).
So, not only can you fetch raw data from the portal through API calls but you can also access high level features such as geo clustering and analytics to directly fuel advanced usages on any kind of devices. This makes it extremely easy for an application developer to quickly build a first MVP without having to build any back-end.
While APIs are a key feature of Open Data portals, one must not forget a major caveat: potential lack of interoperability. While some advanced features can still be made available through non standardized proprietary APIs, it is really key for a data platform to maximize its support of standards. In terms of message formats (JSON, GeoJSON, RSS, RDF...), of protocols (REST, OData...) and security frameworks (OpenId, OAuth, SAML...). Supporting standards is the only way to get the developers community eager to use data portals APIs.
Another good property of "API first" development is that it encourages the development of reusable frameworks based on these APIs. Indeed, an Open Data portal shouldn't exclusively target experienced developers. It should also give to any citizen the possibility to simply reuse Web components, to build their own dashboards and data visualizations.
- This is why any standard data visualization built with the OpenDataSoft platform can easily be embedded in a third party Web application (http://public.opendatasoft.com/explore/dataset/chicago_incidents_2001_p…).
- This is also why we recently launched as an Open Source library a set of reusable HTML widgets which can be easily assembled to build data dashboards (http://opendatasoft.github.io/ods-widgets/docs/#/api/ods-widgets.direct…).
So, If I may summarize this in a few statements:
- API [First] development shall be mandatory.
- Developing and supporting standards will become more and more important.
- Providing tools and frameworks to ease the reuse of datasets exposed on an Open Data portal is also a key factor of success of an Open Data policy.
Authored Comments
Hi Jason,
Indeed, I couldn't agree more. API is a key element to foster data based innovation.
At OpenDataSoft (http://www.opendatasoft.com), we are building and operating a Cloud based data management platform. This platform is built "API first". It means that any feature that can be accessed from the portal is also available as an API call. And actually, the portal is itself the first consumer of the API. Available APIs include (see http://docs.opendatasoft.com/collection/1382-using-apis for more details):
- Dataset catalog APIs (keyword and facetted search of datasets within the catalog).
- Dataset APIs (search within dataset records, geo clustering of geo dataset records, numerical aggregations of dataset records).
So, not only can you fetch raw data from the portal through API calls but you can also access high level features such as geo clustering and analytics to directly fuel advanced usages on any kind of devices. This makes it extremely easy for an application developer to quickly build a first MVP without having to build any back-end.
While APIs are a key feature of Open Data portals, one must not forget a major caveat: potential lack of interoperability. While some advanced features can still be made available through non standardized proprietary APIs, it is really key for a data platform to maximize its support of standards. In terms of message formats (JSON, GeoJSON, RSS, RDF...), of protocols (REST, OData...) and security frameworks (OpenId, OAuth, SAML...). Supporting standards is the only way to get the developers community eager to use data portals APIs.
Another good property of "API first" development is that it encourages the development of reusable frameworks based on these APIs. Indeed, an Open Data portal shouldn't exclusively target experienced developers. It should also give to any citizen the possibility to simply reuse Web components, to build their own dashboards and data visualizations.
- This is why any standard data visualization built with the OpenDataSoft platform can easily be embedded in a third party Web application (http://public.opendatasoft.com/explore/dataset/chicago_incidents_2001_p…).
- This is also why we recently launched as an Open Source library a set of reusable HTML widgets which can be easily assembled to build data dashboards (http://opendatasoft.github.io/ods-widgets/docs/#/api/ods-widgets.direct…).
So, If I may summarize this in a few statements:
- API [First] development shall be mandatory.
- Developing and supporting standards will become more and more important.
- Providing tools and frameworks to ease the reuse of datasets exposed on an Open Data portal is also a key factor of success of an Open Data policy.