Home

Contents

• Introduction
• API design
• Deployment
• Building

See also:

• Development
• Configuration
• Handling codelists
• Generated SPARQL
• Performance musings

Introduction

The data services API projects a regularized view of data from an RDF graph which can be efficiently discovered, introspected and filtered. For naturally regular data such as a Data Cube then it should be sufficiently to point to the DSD to get a fully functional API. It should also be possible to create a regular view over the data by specifying a pseudo-DSD, including support for path expressions.

The key pieces of capability that will be incrementally added are:

• basic dataset list and structure description
• base data query API
• diagnostic pathway to enable a detailed trace of processing to be obtained for debug
• navigation of hierarchical aspects (aka codelist API)
• text search
• geo queries
• temporal queries
• metrics to enable query optimization
• caching
• data characterization queries - maybe

API design

Links off to the parts of the API design. Being filled in incrementally and out-of-order. Based heavily on existing Epiq data cube API design sketch.

• service endpoint URI structure: endpoint URI structure

• descriptions of components of the data: dataset descriptions

• the JSON data query syntax

• responses to queries for (non-meta) data: data query response

• pending

Deployment

The data services API is delivered as a library and as a packaged web application (building on appbase).

Snapshot and released versions of the war are available from our internal Maven repository.

A base deployment is provided as a Vagrant configuration with a shell-based provisioner.

cd data-api-app/deploy/
vagrant up local

This should build a virtual machine with Apache Tomcat7, the dsapi war installed and nginx as a front end. The dsapi service will load data from /opt/dsapi/data at start up and dynamically load data set configurations from /opt/dsapi/conf.

Building

During development changes are being made to both dsapi and the underlying libraries. So the most reliable way to build is to clone and mvn install copies of those:

• lib - git@github.com:epimorphics/lib.git
• appbase - git@github.com:epimorphics/appbase.git

Then mvn install in the data-API project. It's a multi-module project with the core code in data-api-lib and the miniserver in data-api-app.

Invoking run.server with java -jar and the right classpath starts a server running on port 8080.

The same URIs should work if mvn tomcat:run is used to run the webapp.