4 Resource Versioning 4.1 Versioned Resources - MUST provide TimeGate interaction model, detailed below
4.1.1 HTTP GET (LDPRv) The Accept-Datetime header is used to request a past state, exactly as per [ RFC7089 ] section 2.1.1. A successful response must be a 302 (Found) redirect to the appropriate LDPRm If no LDPRm is appropriate to the Accept-Datetime value, an implementation should return a 406 (Unacceptable).- The response to a GET request on an LDPRv must include the following headers:
4.1.2 HTTP PUT (LDPRv) (Danny Bernstein) An implementation must support PUT, as is the case for any LDPR. 4.2 Version Resources (LDPRm) An LDPRm may be deleted An LDPRm must not be modified once created.
4.2.1 HTTP GET (LDPRm) An implementation must support GET, as is the case for any LDPR (LDP-RS memento) An implementation must support GET, as is the case for any LDPR (LDP-NR memento) The headers for GET requests and responses on this resource must conform to [ RFC7089 ] section 2.1 . Particularly it should be noted that the relevant TimeGate for an LDPRm is the original versioned LDPRv . Any response to a GET request must include a <http://mementoweb.org/ns#Memento>; rel="type" link in the Link header.
4.2.2 HTTP OPTIONS (LDPRm) An implementation must support OPTIONS. A response to an OPTIONS request must include Allow: GET, HEAD, OPTIONS An implementation may include Allow: DELETE if clients can remove a version from the version history
4.2.3 HTTP POST (LDPRm) An implementation must not support POST for LDPRms.
4.2.4 HTTP PUT (LDPRm) An implementation must not support PUT for LDPRms.
4.2.5 HTTP PATCH (LDPRm) An implementation must not support PATCH for LDPRms.
4.2.6 HTTP DELETE (LDPRm) An implementation may support DELETE for LDPRms. If DELETE is supported, the server is responsible for all behaviors implied by the LDP-containment of the LDPRm. 4.3 Version Containers (LDPCv) (Jared Whiklo) An implementation must indicate TimeMap in the same way it indicates the container interaction model of the resource via HTTP headers. An implementation must not allow the creation of an LDPCv that is LDP-contained by its associated LDPRv.
4.3.1 HTTP GET (LDPCv) (Jared Whiklo) An implementation must support GET, as is the case for any LDPR. Any response to a GET request must include a <http://mementoweb.org/ns#TimeMap>; rel="type" link in the Link header. An LDPCv must respond to GET Accept: application/link-format as indicated in [ RFC7089 ] section 5 and specified in [ RFC6690 ] section 7.3. An implementation must include the Allow header If an LDPCv supports POST, then it must include the Accept-Post header If an LDPCv supports PATCH, then it must include the Accept-Patch header
4.3.2 HTTP OPTIONS (LDPCv) (Jared Whiklo) Implementations MUST support OPTIONS Implementation's response to an OPTIONS request MUST include "Allow: GET, HEAD, OPTIONS" Implementations may Allow: DELETE if the versioning behavior is removable by deleting the LDPCv Implementations may Allow: PATCH if the LDPCv has mutable properties Implementations may Allow: POST if versions can be explicitly minted by a client If an LDPCv supports POST, the response MUST include the "Accept-Post" header If an LDPCv supports PATCH, the response MUST include the "Accept-Patch" header
4.3.3 HTTP POST (LDPCv) 4.3.3.1 Implementations that allow POSTs for LDPCvs If an LDPCv supports POST , a POST request that does not contain a Memento-Datetime header should be understood to create a new LDPRm contained by the LDPCv, reflecting the state of the LDPRv at the time of the POST . If an LDPCv supports POST , a POST request that does not contain a Memento-Datetime header MUST ignore any request body If an LDPCv supports POST , a POST with a Memento-Datetime header should be understood to create a new LDPRm contained by the LDPCv, with the state given in the request body If an LDPCv supports POST , a POST with a Memento-Datetime header should be understood to create a new LDPRm contained by the LDPCv, with the datetime given in the Memento-Datetime request header.
4.3.3.2 Implementations that disallow POSTs for LDPCvs If an implementation does not support one or both of POST cases above, it must respond to such requests with a 4xx range status code and a link to an appropriate constraints document
4.3.4 HTTP PUT (LDPCv) Implementations MAY disallow PUT
4.3.5 HTTP PATCH (LDPCv) Implementations MAY disallow PATCH
4.3.6 HTTP DELETE (LDPCv) An implementation may support DELETE . An implementation that does support DELETE should do so by both removing the LDPCv and removing the versioning interaction model from the original LDPRv.
4.4 Implementation Patterns |