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
- The response is a 200 instead of the expected 302.
- If no LDPRm is appropriate to the Accept-Datetime value, an implementation should return a 406 (Unacceptable).
- curl -v -X GET http://localhost:8080/rest/test -H "Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT" returns 200.
- todo - ensure that 406 is return (instead of 404) when the LDPCv is empty. (dbernstein)
- 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 LDPCvmust 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
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2811 |
---|
| todo: create JIRA to add Accept-Post header on LDPCv
- If an LDPCv supports PATCH, then it must include the Accept-Patch header - PATCH not supported
- An LDPCv, being a container must have a "Link: <http://www.w3.org/ns/ldp#Container>;rel="type"" header
Jira |
---|
server | DuraSpace JIRA |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-2809 |
---|
|
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) - Although an LDPCv is both a TimeMap and an LDPC, it may disallow POST requests. - POST is allowed
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 - we should disallow
4.3.5 HTTP PATCH (LDPCv) - Implementations MAY disallow PATCH - disallowed
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 |