Hello,Univ.-Doz.Dr. Wolfgang A. Lenhardt
I have a few comments after reading the updated specification:
- The "Required" column in the specification is a little ambiguous.
Â Either 1) the parameter is required to be supported, which I
suspect is the intent, or 2) the parameter is required for each request.
- The event "text" format looks a lot like CSV, why not CSV?
And a couple general comments, not specific to the latest changes:
- The POST method circumvents any HTTP caching. Â I would suggest
this be optional, because the requests could be broken into smaller
GET requests that are cacheable.
- HTTP status 413 (Request Entity Too Large) refers to the _request
body_ being too large, rather than the _response content_ being too
large. Â It's possible an application firewall inserted into a
network between the provider and client would generate this response
even if the query would otherwise be acceptable by the provider;
particularly with POST requests.
One alternative would be 400 Bad Request when exceeding search
limit, and specified "limit" and "count" methods so an agent could
determine the result size was too large.
On Wed, Sep 18, 2013 at 10:39 PM, Chad Trabant
Hello WG III members,
As presented at the WG meeting in Gothenburg, Sweden, below is a
list of FDSN web service additions proposed by the IRIS DMC. Â With
the exception of the POST submission method to fdsnws-station, all
of these changes are in production at the IRIS DMC.
To provide further details and clarify how the changes would alter
the specification, a draft version is attached with additions
highlighted in red.
We proposed that these additions to the 1.0 specification become
version 1.1 of the specification.
* Designate optional versus required parameters for each service
interface. Â Effectively defining a minimum level of functionality
that clients can expect. Â The WADL return from each service
interface specifies which of the optional parameters are supported.
* Allow fdsnws-station to accept arbitrary selections via the POST
method. Â Support for this method is required for all 1.1
implementations of the service. Â The request is to be formatted
similarly to the POST selection method supported by
fdsnws-dataselect, where parameter key-value pairs are followed by a
block of windowed channel requests.
* Add optional 'format' parameter to all three interfaces. Â The
default value for the fdsnws-station and fdsnws-event services is
'xml' (returning FDSN StationXML and QuakeML respectively), an
additional value of 'text' is defined as returning results in a
simple ASCII format (illustrated in the specification). Â The
default value for fdsnws-dataselect is 'miniseed'. Â Future
expansion of the accepted values for this parameter are anticipated
to return the results in alternate formats.
* Add optional 'nodata' parameter to all three interfaces accepting
values of '204' and '404' to control the HTTP status code returned
when a successful request matched no data. Â The default value is '204'.
* Add optional 'matchtimeseries' parameter to fdsnws-station to
limit the results to matching data availability times.
* Clarify definition of starttime and endtime parameters to
explicitly include intersection with metadata epochs.
* Clarify definition of minimum and maximum latitude and longitude
to be inclusive by adding "or equal to".
Except the POST method addition to fdsnws-station, all other
additions are optional. Â Service implementations should return a
WADL which appropriately advertises the optional features supported.
fdsn-wg3-products mailing list
fdsn-wg3-products mailing list