Differential D4248 Diff 15030 docs/specs/blueprint.rst

Changeset View

Standalone View

docs/specs/blueprint.rst

Show All 30 Lines	4. The server notifies the client it acknowledged the client's request. An
``http 201 Created`` response with a deposit receipt in the body response is		``http 201 Created`` response with a deposit receipt in the body response is
sent back. That deposit receipt will hold the necessary information to		sent back. That deposit receipt will hold the necessary information to
eventually complete the deposit later on if it was incomplete (also known as		eventually complete the deposit later on if it was incomplete (also known as
status ``partial``).		status ``partial``).

Schema representation		Schema representation
^^^^^^^^^^^^^^^^^^^^^		^^^^^^^^^^^^^^^^^^^^^

.. raw:: html		Scenario: pushing a deposit via SWORD protocol (nominal scenario)

<!-- {F2884278} -->		.. figure:: ../images/deposit-create-chart.svg

.. figure:: ../images/deposit-create-chart.png
:alt:		:alt:


		Deposit statuses:

		'partial'
		The deposit is new or partially received, since it can be done in
		multiple requests

		'expired'
		Deposit was there too long and is new deemed ready to be
		garbage-collected

		ardumontUnsubmitted Not Done Inline Actions verified. we are missing the deposited status... [1] [1] https://forge.softwareheritage.org/source/swh-deposit/browse/master/docs/images/status.png ardumont: verified. we are missing the deposited status... [1] [1] https://forge.softwareheritage.
		ardumontUnsubmitted Not Done Inline Actions D4260 and in the end i renamed all status names. ardumont: D4260 and in the end i renamed all status names.
		'ready'
		Deposit is fully received and ready for injection

		'injecting'
		Injection is ongoing on SWH's side

		'success'
		Injection successful

		'failure'
		Injection failure



Updating an existing deposit		Updating an existing deposit
~~~~~~~~~~~~~~~~~~~~~~~~~~~~		~~~~~~~~~~~~~~~~~~~~~~~~~~~~

5. Client updates existing deposit through the update uris (one or more POST		5. Client updates existing deposit through the update uris (one or more POST
or PUT requests to either the edit-media iri or edit iri).		or PUT requests to either the edit-media iri or edit iri).

1. Server validates the client's input or returns detailed error if any		1. Server validates the client's input or returns detailed error if any

Show All 11 Lines	.. note::
but we are planning to allow depositing metadata in the ``done`` state		but we are planning to allow depositing metadata in the ``done`` state
as well.		as well.
In this state, ``In-Progress`` is not allowed, so the deposit cannot go back		In this state, ``In-Progress`` is not allowed, so the deposit cannot go back
in the ``partial`` state, but only to ``deposited``.		in the ``partial`` state, but only to ``deposited``.

Schema representation		Schema representation
^^^^^^^^^^^^^^^^^^^^^		^^^^^^^^^^^^^^^^^^^^^

.. raw:: html		Scenario: updating a deposit via SWORD protocol

<!-- {F2884302} -->

.. figure:: ../images/deposit-update-chart.png		.. figure:: ../images/deposit-update-chart.svg
:alt:		:alt:


		Deposit statuses:

		'partial'
		The deposit is new or partially received, since it can be done in
		multiple requests

		'expired'
		Deposit was there too long and is new deemed ready to be
		garbage-collected

		'ready'
		Deposit is fully received and ready for injection

		'injecting'
		Injection is ongoing on SWH's side

		'success'
		Injection successful

		'failure'
		Injection failure

Deleting deposit (or associated archive, or associated metadata)		Deleting deposit (or associated archive, or associated metadata)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~		~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

6. Deposit deletion is possible as long as the deposit is still in ``partial``		6. Deposit deletion is possible as long as the deposit is still in ``partial``
state.		state.

1. Server validates the client's input or returns detailed error if any		1. Server validates the client's input or returns detailed error if any
2. Server actually delete information according to request		2. Server actually delete information according to request

Schema representation		Schema representation
^^^^^^^^^^^^^^^^^^^^^		^^^^^^^^^^^^^^^^^^^^^

.. raw:: html		Scenario: deleting a deposit via SWORD protocol

<!-- {F2884311} -->

.. figure:: ../images/deposit-delete-chart.png		.. figure:: ../images/deposit-delete-chart.svg
:alt:		:alt:


		Deposit statuses:

		'partial'
		The deposit is new or partially received, since it can be done in
		multiple requests

		'expired'
		Deposit was there too long and is new deemed ready to be
		garbage-collected

		'ready'
		Deposit is fully received and ready for injection

		'injecting'
		Injection is ongoing on SWH's side

		'success'
		Injection successful

		'failure'
		Injection failure

Client asks for operation status		Client asks for operation status
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~		~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

7. Operation status can be read through a GET query to the state iri.		7. Operation status can be read through a GET query to the state iri.

Server: Triggering deposit checks		Server: Triggering deposit checks
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~		~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Show All 15 Lines