Should throw a NotImplementedHttpError if the DataAccessor does not support storing the given Representation.
BadRequestHttpError If it does not support the incoming data.
Incoming Representation.
Deletes the resource and its corresponding metadata.
Solid, ยง5.4: "When a contained resource is deleted, the server MUST also remove the corresponding containment triple, which has the effect of removing the deleted resource from the containing container." https://solid.github.io/specification/protocol#deleting-resources
Resource to delete.
Returns metadata for all resources in the requested container. This should not be all metadata of those resources (but it can be), but instead the main metadata you want to show in situations where all these resources are presented simultaneously. Generally this would be metadata that is present for all of these resources, such as resource type or last modified date.
It can be safely assumed that the incoming identifier will always correspond to a container.
Identifier of the parent container.
Returns a data stream stored for the given identifier. It can be assumed that the incoming identifier will always correspond to a document.
Identifier for which the data is requested.
Returns the metadata corresponding to the identifier.
If possible, it is suggested to add a posix:size
triple to the metadata indicating the binary size.
This is necessary for range requests.
Identifier for which the metadata is requested.
Writes metadata for a container. If the container does not exist yet it should be created, if it does its metadata should be overwritten, except for the containment triples.
Identifier of the container.
Metadata to store.
Writes data and metadata for a document. If any data and/or metadata exist for the given identifier, it should be overwritten.
Identifier of the resource.
Data to store.
Metadata to store.
Writes metadata for a resource. It can safely be assumed that the subject resource already exists.
Identifier of the subject resource.
Metadata to store.
The AtomicDataAccessor interface has identical function signatures as the DataAccessor, with the additional constraint that every function call must be atomic in its effect: either the call fully succeeds, reaching the desired new state; or it fails, upon which the resulting state remains identical to the one before the call.