Project

General

Profile

Feature #725

Support arbitrary endpoint to action mapping

Added by Chad Trabant almost 9 years ago. Updated over 8 years ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
Start date:
08/18/2015
Due date:
% Done:

0%

Estimated time:
Resolution:
Fixed

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:

  1. "className#<classname>", identifying a Java class name to be invoked for each request
  2. a URI, identifying content to be proxied (fetched and relayed) to the client, e.g. starting with file://, http://
  3. 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 almost 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 almost 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 over 8 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

Also available in: Atom PDF