...
Expand | ||||||||
---|---|---|---|---|---|---|---|---|
3.1 General (Jared Whiklo)
3.1.1 LDP Containers
3.1.2 LDP-NR creation
3.1.3 Constraints Document
3.1.4 Data Model
3.2 HTTP GET3.2.1 Additional values for the Prefer header
3.2.2 LDP-RSs
3.2.3 LDP-NRs
3.3 HTTP HEAD
3.4 HTTP OPTIONS (Yinlin Chen)
3.5 HTTP POST
3.5.1 LDP-NRs
3.6 HTTP PUT
3.6.1 LDP-RSs
3.6.2 LDP-NRs (Danny Bernstein)
3.6.3 Creating resources with HTTP PUT
3.7 HTTP PATCH (Jared Whiklo)
3.7.1 Containment Triples 3.7.2 Interaction models
3.8 HTTP DELETE (Yinlin Chen)
3.7.2 Interaction models
3.8 HTTP DELETE (Yinlin Chen)
3.8.3.8.1 Recursive Delete
3.3.9 External Binary Content
3.9.1 Advertising External Content Support
3.9.2 External Content for RDF Resources
3.9.3 Redirected and Proxied External Content
|
4 Versioning
Leads
...
- 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
- 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:
- 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.
...
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.
...
- 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)
4.3.3.1 Implementations that allow POSTs for LDPCvs
- If an LDPCv supports
POST
, aPOST
request that does not contain aMemento-Datetime
header should be understood to create a new LDPRm contained by the LDPCv, reflecting the state of the LDPRv at the time of thePOST
. - If an LDPCv supports
POST
, aPOST
request that does not contain aMemento-Datetime
header MUST ignore any request body - If an LDPCv supports
POST
, aPOST
with aMemento-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
, aPOST
with aMemento-Datetime
header should be understood to create a new LDPRm contained by the LDPCv, with the datetime given in theMemento-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)
...
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
3.9.1 Advertising External Content Support
3.9.2 External Content for RDF Resources
3.9.3 Redirected and Proxied External Content
|
4 Versioning
Leads
Expand | ||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
4 Resource Versioning
4.1 Versioned Resources
4.1.1 HTTP GET (LDPRv)
4.1.2 HTTP PUT (LDPRv) (Danny Bernstein)
4.2.1 HTTP GET (LDPRm)
4.2.3 HTTP POST (LDPRm)
4.2.4 HTTP PUT (LDPRm)
4.2.5 HTTP PATCH (LDPRm)
4.2.6 HTTP DELETE (LDPRm)
4.3.1 HTTP GET (LDPCv) (Jared Whiklo)
4.3.2 HTTP OPTIONS (LDPCv) (Jared Whiklo)
4.3.3 HTTP POST (LDPCv) 4.3.3.1 Implementations that allow POSTs for LDPCvs
4.3.3.2 Implementations that disallow POSTs for LDPCvs
4.3.4 HTTP PUT (LDPCv)
4.3.5 HTTP PATCH (LDPCv)
4.3.6 HTTP DELETE (LDPCv)
4.4 Implementation Patterns
|
5 Resource Authorization
Leads
Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
5. Resource Authorization
5.1 ACLs are LDP RDF Sources
5.2 ACL Representation and Interpretation (Danny Bernstein)
5.3 ACLs are discoverable via Link Headers
5.4 ACL linking on resource creation (Peter Eichman)
5.5 Cross-Domain ACLs (Peter Eichman)
5.6 Cross-Domain Group Listings
5.7 Append Mode
5.7.1 LDP-RS (Append)
5.7.2 LDPC (Append) |
5 Resource Authorization
Leads
Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
5. Resource Authorization
5.7.3 LDP-NR (Append)
key | FCREPO-2745 | 5.1 ACLs are LDP RDF Sources5.2 ACL Representation and Interpretation (Danny Bernstein)
5.3 ACLs are discoverable via Link Headers
5.4 ACL linking on resource creation
5.5 Cross-Domain ACLs
5.6 Cross-Domain Group Listings
5.7 Append Mode
5.7.1 LDP-RS (Append)
5.7.2 LDPC (Append) When a client is allowed to performacl:Append but not acl:Write operations on an LDPC, a POST request MUST be allowed.5.7.3 LDP-NR (Append) When a client is allowed to performacl:Append but not acl:Write operations on an LDP-NR:
5.8 Access To Class
5.9 Inheritance and Default ACLs
5.8 Access To Class
5.9 Inheritance and Default ACLs
|
6 Notifications
Lead
Expand |
---|
6.1 Notification Events
6.2 Notification Serialization
6.3 Examples
|
...