Page History

• When an  LDPR  is created with a  rel="type"  link in the  Link  header specifying type http://mementoweb.org/ns#OriginalResource to indicate versioning, it must  be created as an LDPRv
• When an  LDPR  is created with a  rel="type"  link in the  Link  header specifying type http://mementoweb.org/ns#OriginalResource to indicate versioning, a version container (LDPCv) capturing time-varying representations of the LDPRv MUST be created
  • todo: create JIRA requiring the LDPCv to have: "Link: <http://www.w3.org/ns/ldp#Container>;rel="type""

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).
  • curl -v -X GET http://localhost:8080/rest/test -H "Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT" returns 200.
• The response to a GET request on an LDPRv must include the following headers:
  •  A rel="original timegate" link in the Link header referencing itself (Jared Whiklo)
  • A <http://mementoweb.org/ns#TimeGate>; rel="type" link in the Link header (Jared Whiklo)
  • A <http://mementoweb.org/ns#OriginalResource>; rel="type" link in the Link header
  • At least one rel="timemap" link in the Link header referencing an associated LDPCv
  • A Vary: Accept-Datetime header, exactly as per [ RFC7089 ] section 2.1.2.

4.1.2 HTTP PUT (LDPRv) (Danny Bernstein)

• An implementation must support PUT, as is the case for any LDPR.

• 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.

•  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
  • 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

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

  • todo: create JIRA to return a 405 instead of the current 400 on:

    Code Block
    curl -i -u fedoraAdmin:fedoraAdmin -XPUT -H"Content-Type: application/sparql-update" @patch.ru localhost:8080/rest/test4/obj/fcr:versions/new

    
    

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

• Non-normative section