[jira] [Created] (JENA-1715) Improvements to Fuseki request dispatch

["Andy Seaborne (JIRA)" <ji...@apache.org>]

Andy Seaborne created JENA-1715:
-----------------------------------

             Summary: Improvements to Fuseki request dispatch
                 Key: JENA-1715
                 URL: https://issues.apache.org/jira/browse/JENA-1715
             Project: Apache Jena
          Issue Type: Improvement
          Components: Fuseki
    Affects Versions: Jena 3.12.0
            Reporter: Andy Seaborne
            Assignee: Andy Seaborne
             Fix For: Jena 3.13.0


Dispatching HTTP requests in Fuseki can be cleaned up. Some cases are inelegant
bolt-ons (such as operations directly on the dataset). This breaks down when
we try to have detailed configuration of service/endpoint, especially for
access control.

With this JIRA:
      
* There is one dispatch mechanism applied in all case (before, there were hard-coded variations).
* Multiple endpoints can be attached to the same service point (a name) whether on the datasets ("/dataset") or services (e.g. "/dataset/sparql") giving the user freedom of design for naming and access control.
* Operations on "/dataset" and operations on services can dispatch by request type (query, update, GSP). This makes "/dataset/sparql" work for all SPARQL operations. Currently, that only works on "/dataset". 
* Quads and GSP (Graph Store Protocol) operations are combined into "Extended GSP" operations, not a hardcoded dispatch special case.

"Quads" operations are the usual HTTP GET/POST/PUT/PATCH on the dataset itselt, (not DELETE, mainly to avoid accidents.
      
There would be no changes to applications using Fuseki configuration files. The
existing vocabulary is used to create new style backwards compatible configurations.
Direct use in Fuseki main java builder, will show differences in cases that were
not supposed to work in the first place (accidental features discovered during preliminary work for this issue).
Normal usage should be the same.
      
It will now be possible, eventually, to have a new, more powerful configuration:
  
Sketch, not fro this issue, of a query operation on the dataset (there is no "name" given),
with access control, timeout, union setting and query result limit, and query and update services on "sparql".
{noformat}
<#service> rdf:type fuseki:Service ;
    fuseki:name "/ds" ;
    fuseki:endpoint [
        fuseki:operation     fuseki:Query ;
        fuseki:allowedUsers  (....) ;
        fuseki:timeout       "1000,10000" ;
        fuseki:queryLimit    1000;
        arq:unionGraph       true;
    ] ;
    fuseki:endpoint [
        fuseki:name "sparql" ;  ## becomes "/ds/sparql"
        fuseki:operation     fuseki:Query ;
        ...
    ] ;
    fuseki:endpoint [
        fuseki:name "sparql" ;
        fuseki:operation     fuseki:Update ;
        ...
    ] ;
.
{noformat}




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)