Graph Store Replication HTTP Protocol¶
The “Graph Replication Protocol” extends the W3C “SPARQL Graph Store HTTP Protocol” to combine distributed repositories instances into a replicated store. A replicated repository differs from a standard (revisioned) repository in that each statement history records those respective insertion/deletion revision identifiers specific to that statement. These histories are propagated and merged into each replica. Each history provides an unambiguous record of the statement’s presence at each point in time. Once their state of all replicas converges, all histories are identical.
replication requests¶
Replication requests are addressed to the graph store replication end point
http://dydra.com/<account-name>/<repository-name>/replication
Any graph may be specified indirectly. The operations are analogous to those of the graph store protocol:
upload for import
replacement (PUT)
addition (POST)
modification (PATCH)
clearing (DELETE)
download for export (GET)
Once an operation completes, it is propagated to all known replicas. The propagated requests supply a transaction identifier along with the content for merging. If the client request includes an identifier, it is a remote request and the identifier is retained. Local requests include no identifier and the respective local transaction identifier is used.
No SPARQL support is present.
HEAD¶
A HEAD request registers the client as a replication peer. All subsequent replication operations are then passed to the client at the specified location.
Headers¶
Location: URL target for replication requests
DELETE¶
A DELETE request removes the content statements from the repository.
Headers¶
Content-Type: specifies the RDF content document media type.Graph: specifies the statement context uri.Revision: Identifies the Universal Revision ID to associate with the new content
GET¶
A GET request returns the repository content. If a revision is specified, the response contains those present as of that revision. A request without a revision operates on the latest revision.
Headers¶
Accept: specifies the RDF response document media type.Graph: specifies the context constraint.
PUT¶
A PUT request clears the repository and inserts the request content.
Headers¶
Content-Type: specifies the RDF content document media type.Revision: Identifies the Universal Revision ID to associate with the new content
POST¶
A POST request appends the content to the repository.
Headers¶
Content-Type: specifies the RDF content document media type.Revision: Identifies the Universal Revision ID to associate with the new content
PATCH¶
A PATCH encodes changes to the repository as a multipart/related mime message. Each request part modifies the repository as per the respective X-HTTP-Method-Override header
Headers¶
Content-Type: specifies the RDF content document media type.Graph: specifies the statement context uri.Revision: Identifies the Universal Revision ID to associate with the new content
Part Headers¶
Content-Type: specifies the RDF part document media type.Graph: specifies the part statement context uri.X-HTTP-Method-Override: specifies the operation (PUT, POST, PATCH, or DELETE) to apply to the part content.