The events endpoint will return data in the format
agreed with Multiseis if the request has an
Accept: application/vnd.seis+json
header.
Related to #12.
The reason for refactoring was to accommodate
Multiseis / client sequence exports, which will be
served by this endpoint via a specific Content-Type.
In the process, the cache has been fixed and redesigned.
Related to #12.
This is not really a substitute for proper database
design but if deemed useful it might be refactored
into a more generic caching middleware and applied
to other requests as a low-cost alternative to
database refactoring while we gain usage and
performance information.
An alert is sent whenever an endpoint returns
an error other than an explicit failure (e.g.,
it won't send an alert if a middleware intentionally
returns a {status: XXX} object).
The endpoint /project/:project/configuration/:path(*)?
returns the contents of the survey configuration YAML
file for a given project.
To retrieve the full configuration:
* /project/:project/configuration
To retrieve a specific subset (e.g., binning parameters):
* /project/:project/configuration/binning
To retrieve a specific value (e.g., inline bin width):
* /project/:project/configuration/binning/I_width
Labels can be associated with events and can have
display properties such as a description and colour,
this is why we need an endpoint for the client to
retrieve them.
Events may be filtered by sequence(s):
…/event?sequence=1
…/event?sequence=1;3;7
Events may be filtered by date:
…/event?date0=1970-01-01
Events may be filtered by a date interval:
…/event?date0=1970-01-01&date1=1980-01-01
Events may also be paginated.
