A DataAccessor is the building block closest to the actual data storage. It should not worry about most Solid logic, most of that will be handled before it is called. There are a few things it still needs to do, and it is very important every implementation does this:
Should throw a NotImplementedHttpError if the DataAccessor does not support storing the given Representation.
BadRequestHttpError If it does not support the incoming data.
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.
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.
Writes data and metadata for a document. If any data and/or metadata exist for the given identifier, it should be overwritten.