You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »


The table below is derived from the following document

Fedora API Spec and Delta Document Verification


Issue DescriptionSpec ReferencePriorityDifficultyRelated JIRAsDepends onNotes

Change the PreferInboundReferences URI in Prefer header

from http://fedora.info/definitions/v4/repository#InboundReferences to the one defined in the spec (ie http://fedora.info/definitions/fcrepo#PreferInboundReferences)

3.2.111


HTTP Head does not return the same headers as if the request were a GET3.3




POSTing a LDP-NR does not return correct constrainedBy Link header3.5




MUST return 409 if request's type Link is not resource's current type or subtype thereof, or not in LDP namespace
  • Though the message coming back in the case of an attempt to move from RDFSource to NonRDFSource says "Resource Already Exists" instead of returning a constrained by header
  • Same message is returned trying to move from ldp:Container to an ldp:DirectContainer or ldp:BasicContainer or ldp:Container

MUST change resource's type if request's type Link is a subtype of resource's current type

MUST change resource's interaction model if request's type Link has an LDP interaction model

3.6




Using PATCH it is currently possible to add an rdf:type of ldp:NonRDFSource to an existing ldp:RDFSource. This should not 3.7.1




Replace current Link rel="type" Header with memento specified link (i.e. http://mementoweb.org/ns#OriginalResource) 4.1




The Accept-Datetime header is used to request a past state, exactly as per [RFC7089section 2.1.1. A successful response must be a 302 (Found) redirect to the appropriate LDPRm4.1.1




If no LDPRm is appropriate to the Accept-Datetime value, an implementation should return a 406 (Unacceptable).4.1.1




The response to a GET request on an LDPRv must include the following headers


4.1.1




LDPm GET

  • An implementation must support GET, as is the case for any LDPR.
  • The headers for GET requests and responses on this resource must conform to [RFC7089section 2.1. Particularly it should be noted that the relevant TimeGate for an LDPRm is the original versioned LDPRv.
  • In addition, any response to a GET request must include a <http://mementoweb.org/ns#Memento>; rel="type" link in the Link header.
4.2.1

find existing

LPPm OPTIONS

  •  An implementation must support OPTIONS.
  •  A response to an OPTIONS request must include Allow: GET, HEAD, OPTIONS as per [LDP].
  •  An implementation may include Allow: DELETE if clients can remove a version from the version history, as noted in 3.8 HTTP DELETE.
4.2.2




LDPm: PUT, POST, and PATCH must return 405 method not allowed4.2.3-5




LDPm: DELETE

The server is responsible for all behaviors implied by the LDP-containment of the LDPRm.

4.2.6



This is a MAY: Are we planning to implement?

LDPCv : 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. Currently the <http://fedora.info/definitions/v4/repository#TimeMap> is being used.


4.3.2




LDPCv: Disallow PUT and PATCH4.3.2




LDPCv: HTTP POST:

  • POST 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. Any request body must be ignored.
  • A Memento-Datetime header should be understood to create a new LDPRm contained by the LDPCv, with the state given in the request body and the datetime given in the Memento-Datetime request header.
4.3.3




LDPCv: DELETE:

Delete of an LDPCv must remove the LDPCv and removing the versioning interaction model from the original LDPRv.

4.3



Are we planning to support?

Vary :

When an LDPCv supports POST, and allows clients to specify a datetime for created URI-Ms, Vary-Post/Vary-Put: Memento-Datetime.

4.4




  • No labels