Feature #725
Support arbitrary endpoint to action mapping
0%
Description
Support arbitrary command line mapping between endpoint methods and actions. A list of mappings might, in configuration file form, look like:
endpoints=[<method>:<action>,<method>:<action>,...]
where <method> is the endpoint relative to the base deployment path, e.g. "query", "queryauth", "info", "catalogs" and <action> is one of three definitions:
- "className#<classname>", identifying a Java class name to be invoked for each request
- a URI, identifying content to be proxied (fetched and relayed) to the client, e.g. starting with file://, http://
- otherwise a command line executable to invoke as a handler for each request
A few, minimal fixed endpoints should be retained as hard coded paths, such as <path>/wssversion.
History
#1 Updated by Chad Trabant about 9 years ago
An example endpoints parameter for the DMC's fdsnws-dataselect service might look like:
endpoints=/:http://service/fdsnws/dataselect/docs/1/root/, \
application.wadl:http://service/fdsnws/dataselect/docs/1/wadl/, \
query:/opt/dmc/bin/extractdata-handler, \
queryauth:/opt/dmc/bin/extractdata-handler \
Currently a configuration to achieve a similar results uses these config options:
rootServiceDoc=http://service/fdsnws/dataselect/docs/1/root/ wadlPath=http://service/fdsnws/dataselect/docs/1/wadl/ handlerProgram=/opt/dmc/bin/extractdata-handler
#2 Updated by Mike Stults about 9 years ago
Observations so far
- I am not finding an API in Jersey 1.x for dynamic creation of endpoints, there is an API in Jersey 2.x
- At first look, dynamic endpoint definition may be problematic with the current WSS design, the current (somewhat circular) design of WSS requires that a web app context exist before the parameter files are read because the name of the web app is used to create a prefix for the name of a parameter file e.g. "dataselect-1-". Testing is needed to see what can be done.
- Depending on how closely related the endpoints are, adding new endpoints (at least those with user parameters) will probably require their own respective set of parameters, outputTypes, etc. else WSS error checking becomes the union of all parameters and their outputTypes across all endpoints.
An example of items that may need to be independent per endpoint
endpoint things_needed
query outputTypes = miniseed, mseed, json ...
parameters = starttime, start, network, net, ...
postEnabled
corsEnabled
handlerTimeout
handlerProgram=/WSSHOME/bin/handlerQuery
use404For204
onDemandSynthetics
outputTypes = sac, ...
parameters = model
postEnabled
corsEnabled
handlerTimeout
handlerProgram=/WSSHOME/bin/handler/requestSynthetics
use404For204
some of these things can be global, but probably not outputTypes, parameters, and handler items.
#3 Updated by Mike Stults almost 9 years ago
- Target version set to 2.0
#4 Updated by Mike Stults over 8 years ago
- Resolution set to Fixed
This will be available with version 2.0