Mulgara

The protocol servlet is getting too many methods, and still needs to expand.

The proposed refactoring is to create classes based on the resource type of the request. Each class then manages operations on the type that it manages.

Resource types are identified by parameters in the request. Care must be taken with POST requests, as parameters may arrive in the content, and not the URL.

• Graphs. These are identified by the inclusion of a default-graph-uri parameter, and none of the other parameters that identify other types. A synonym for this parameter is graph.
• Statements. These are identified by the inclusion of subject, predicate, object, and graph (or default-graph-uri) parameters. Synonyms include: subj/*s*, pred/*p* and obj/*o*. If only some of these are present, or duplicates occur, then this is an error.
• Queries. These are not "resources", but are defined by the SPARQL spec.

• Graph:
  • GET: Issue a CONSTRUCT for the entire graph. TODO.
  • PUT: Create a graph. TODO: return 201
  • DELETE: Delete a graph.
  • POST: Load a file into a graph.
  • HEAD: Return the graph type, if known.
• Statement:
  • GET: An OK response if the statement exists. Otherwise return 404. TODO.
  • PUT: Create the statement. TODO: return 201
  • DELETE: Remove the statement.
  • POST: Take an ID parameter and use this as a URI to reify the statement. TODO.
  • HEAD: Get the Reification ID for the statement. TODO.
• Query:
  • GET: Perform a read-only query.
  • PUT: N/A (should this do an insert/select for construct queries?)
  • DELETE: N/A (should this do an delete/select for construct queries?)
  • POST: Allows writable commands (TQL only. Possibly SPARQL Update.)
  • HEAD: Get the size of the result of a read-only query. TODO.