IDigBio API
The iDb API is a RESTful pattern HTTP API that primarily delivers data in JSON format.
API urls have several parameters in them, and typically follow of the form <base url>/<version>/<type>/<id> when all parameters are included.
For example: "http://api.idigbio.org/v1/mediarecords/8f455ace-5c15-4439-aa2f-07f23f21a5cb" where "http://api.idigbio.org" is the base url, "v1" is the version, "mediarecords" is the collection type,and "8f455ace-5c15-4439-aa2f-07f23f21a5cb" is the entity ID.
There are two major types of API enpoints:
Collection - which is a group endpoint that returns lists of multiple records. These urls are of the form <base url>/<version>/<type>, such as http://api.idigbio.org/v1/mediarecords/ . Entity - A single item endpoint which returns all of the data available about an object. These urls are of the form of the example url above, with all the parameters included.
Additionally, calling just the base URL will return a list of versions such as:
{
v1: "http://api.idigbio.org/v1/",
v0: "http://api.idigbio.org/v0/"
}
and calling the version URL will return a list of major types such as:
{
recordsets: "http://api.idigbio.org/v1/recordsets",
records: "http://api.idigbio.org/v1/records",
mediarecords: "http://api.idigbio.org/v1/mediarecords",
mediaaps: "http://api.idigbio.org/v1/mediaaps",
people: "http://api.idigbio.org/v1/people",
organizations: "http://api.idigbio.org/v1/organizations",
taxa: "http://api.idigbio.org/v1/taxa",
aggregates: "http://api.idigbio.org/v1/aggregates"
}
The idigbio API also tries to follow the REST paradigm's HATEOAS model, which basically means that within each API endpoint we provide a list of relevant links to further API actions. This list typically is stored in either the "idigbio:links" in v1 or below or the "links" property in v3. In general, the largest difference between v1 and v3 responses is that the "idigbio:" namespace has been dropped from all system-level property names.
Other system level property names include
For Entity Endpoints: etag - the ETag of the entity dateModified - The date the entity was modified version - The entity's version number type - The entity's type uuid - The entity's uuid siblings - Any siblings the entity may have as a dictionary of uuids recordIds - A list of lookup keys for the entity data - The entity's encapsulated data element
For collection endpoints: items - the list of items in the collection itemCount - the number of total items in the collection
The data element for each entity can include any number of key-value pairs containing properties of the entity, including potentially values that are themselves lists or dictionaries. Typical key namespaces that might appear in each type are (in order of decreasing usefulness):
Records: typically contains darwin core elements ( http://rs.tdwg.org/dwc/terms/index.htm ) describing a physical specimen, may also contain custom elements or elements defined by other standards. MediaRecords: typically contains audubon core elements ( http://terms.gbif.org/wiki/Audubon_Core_Term_List_(1.0_normative) ) describing a media capture event, may also contain custom elements or elements defined by other standards. MediaAPs: defined internally, contains references to the location of binary media objects within our object stores. RecordSets: currently undefined, in v3 will have a fixed format derived from our collection registration parameters. DataFiles: defined internally, contains references to the location of binary data file objects within our object stores. People: defined internally, contains records of people who have interacted with the iDigBio system, such as data provider contacts, users of the system, or other related people. Organizations: defined internally, contains records of organizations who interact with iDigBio. Right now this primarily contains the data from our collection registrations. Taxa: currently undefined and unused. May eventually hold taxonomic records, most likely following the darwin core standard. Aggregates: currently undefined and unused. May eventual hold incrementally built lists of records, such as the cached results of search queries or manually curated record groups.