POST request to LDPCv to create new
Specification
- 4.1.3.1 In supporting PUT to LDPRv in order to create a LDPRm, is this just included for server managed versions? Or is PUT to an LDPRv intended to be addressable separately from a LDPR so as to trigger this behavior?
- https://github.com/fcrepo/fcrepo-specification/issues/215
- Propose that PUT language is removed and that server managed behaviors are left up to implementors so long as they meet other requirements
- 4.3.1 What is the default serialization for GET requests to LDPCv? The only required encoding is application/link-format.
- This will depend on if the LDPCv remains the same object as the timemap
- 4.3.5 What is the expected behavior if a POST to an LDPCv is made which specifies a Memento-Datetime that is already in use by an existing LDPRm for that LDPRv?
- Having two memento's with the same datetime would result in datetime negotiation yielding indeterminate results.
- Ignore request and return a 412 response? Delete and replace the existing version?
- This could be something we decide - perhaps the new one overwrites the existing one?
- Starting with a 412 response
- 4.5 Does the modeshape fcrepo currently have a server managed option for versioning?
- We need to make sure that a server managed scenario knows how to handle an LDPCv correctly - in that it doesn't version that resource if a user issues a PUT against it (as a user would if they want the original resource LDPRv to get versioned).
...
- 2.2.1 - noted above in 4.2.3: on a GET/HEAD request to a LDPRm or TimeGate (the LDPRv, in this case) a Link header must be returned with relation type of 'original' which points to URI of the original resource (LDPRv)
- 2.2.2 - on a GET/HEAD request to a LDPR or LDPRm, a Link header must be returned with the relation type of 'timegate', which points to the the timegate for the resource.
- multiple timegate Links are possible
- 2.2.3 - on a GET/HEAD request to a LDPR or LDPRm or TimeGate(which is the LDPR, in this case), a Link header must be returned with the relation type of 'timemap', which points to the timemap for the resource.
- support "from" and "until" attributes? These would cause the returned representation of the time map to only include the interval requested.
- the link should make use the 'type' attribute to indicate the mime type of the timemap.
Other questions
- Should LDPRv's return Content-Location and Memento-Datetime headers? The later is required by https://tools.ietf.org/html/rfc7089#section-4.1.2 but may not make sense in fcrepo's usage.
LDPCv Example Response
| Code Block | ||
|---|---|---|
| ||
# GET request to LDPCv curl http://localhost/rest/a/fcr:versions -H "Accept: application/link-format" -v < HTTP/1.1 200 OK < Date: Thu, 21 Jun 2017 00:06:50 GMT < Server: Apache < Content-Type: application/link-format < Allow: GET, HEAD, OPTIONS, POST, PATCH, DELETE < Accept-Post: text/turtle,text/rdf+n3,text/n3,application/rdf+xml,application/n-triples,application/ld+json,multipart/form-data,application/sparql-update < Accept-Patch: application/sparql-update < Connection: close <http://localhost/rest/a>;rel="original timegate", <http://localhost/rest/a/fcr:versions> ; rel="self";type="application/link-format" ; from="Tue, 20 Jun 2016 18:02:59 GMT" ; until="Wed, 09 Apr 2017 20:30:51 GMT", <http://localhost/rest/a/fcr:versions/20160620180259356>; rel="memento";datetime="Tue, 20 Jun 2016 18:02:59 GMT", <http://localhost/rest/a/fcr:versions/version_1>; rel="memento";datetime="Fri, 06 Jan 2017 18:50:11 GMT", <http://localhost/rest/a/fcr:versions/20170409203051112>; rel="memento";datetime="Wed, 09 Apr 2017 20:30:51 GMT", |
...