A conforming Fedora server is a conforming [[!LDP]] 1.0 server except where described in this document that also follows the rules defined by Fedora in , - , , , - , and . + , , + , and .
- Fedora provides factilities by which to conduct multiple operations against a repository - in an atomic fashion. This is accomplished by the use of headers on requests. An atomic - series of operations should not require any more requests than the same series of - operations performed non-atomically. -
-
- A client begins an atomic series of requests by sending any request to any resource with
- the header Atomic-Start. The server MUST respond by including a header
- Atomic-ID with a unique identifier for the series. The effect of the
- request, if it has one, and if the request is successful, MUST be visible to clients
- using that identifier to add to this series of requests, as described
- below, until the series expires or is finished. The effect of the
- request, if it has one, and if the request is successful, SHOULD NOT be visible to
- clients not using that identifier to add to this series of requests. The effect of the
- request MUST NOT be durable unless and until the series is successfully
- finished.
-
- A client adds to an atomic series of requests by sending any request to any resource with
- the header Atomic-ID and the identifier for that series. The effect of the
- request, if it has one, and if the request is successful, MUST be visible to clients
- using that identifier to add to this series of requests, until the series expires or is
- finished. The effect of the request, if it has one, and if the request is successful,
- SHOULD NOT be visible to clients not using that identifier to add to this series of
- requests. The effect of the request MUST NOT be durable unless and until the series is
- successfully finished. An implementation MUST respond
- to any request with multiple Atomic-ID headers with different values or
- with an Atomic-ID header with a value that has not been assigned to a
- series or that has expired (see below) with a 409 response.
- That response MUST include an Atomic-Invalid header or headers with the
- invalid identifier or identifiers.
-
- An implementation MAY enforce automatic expiration for an atomic series of requests.
- If so, the response to any request made as part of the series MUST have a
- Atomic-Expires header with the HTTP datetime at which the series will
- expire. An implementation MAY extend the lifetime of a series upon the receipt of any
- request specifying the unique identifier of that series in the Atomic-ID
- header.
-
- A client can finish an atomic series of requests by sending any
- PUT/POST/PATCH/DELETE request
- including both a Atomic-Commit header and a Atomic-ID
- header with the unique identifier of an existing series. The effects of all requests
- in the series MUST become durable and MUST become visible to all clients. The unique
- identifier of the series MUST be expired and MUST NOT be reused.
-
- A client can finish an atomic series of requests by sending any request including
- both a Atomic-Abort header and a Atomic-ID header with
- the unique identifier of an existing series. The effects of all requests in the
- series MUST disappear to all clients, and MUST be durably gone. The unique identifier
- of the series MUST be expired and MUST NOT be reused.
-