Example 1: Upload a file to a remote repository

In this case, the server is composed of a single content repository. The CID process allows client applications to upload new files in the repository.

Server manifest⚓

1
<?xml version="1.0" encoding="UTF-8"?>
2
<cid:manifest xmlns:cid="http://www.cid-protocol/schema/v1/core" xmlns:xml="http://www.w3.org/XML/1998/namespace"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xsi:schemaLocation="http://www.cid-protocol/schema/v1/core ../manifest/cid-core.xsd ">
3
    <cid:process>
4
        <cid:label xml:lang="fr">Téléversement de fichier</cid:label>
5
        <cid:label xml:lang="en">File upload</cid:label>
6
        <cid:meta name="File-name" is="http://purl.org/dc/elements/1.1/title">
7
            <cid:label xml:lang="fr">Nom du fichier</cid:label>
8
            <cid:label xml:lang="en">File name</cid:label>
9
            <cid:doc xml:lang="en">
10
                The file-name will be used in the public url of the file
11
                Example: http://.../1d57fe87zr45sdz796m/monImage.png
12
            </cid:doc>
13
        </cid:meta>
14
        <cid:meta name="Public-url" is="http://schema.org/URL"/>
15
        <!--
16
            The following fragment is the main part of the process declaration. It
17
            describes each step of the process.
18
            Each step declares the (previously-documented) used (optional), needed
19
            or returned metadatas. This process contains only one step: the upload
20
            step which is required to complete the file deposit and which is
21
            composed by only one request (attribute step="unique"). This step
22
            accepts the File-name metadata and returns the Public-url of the
23
            uploaded file.
24
         -->
25
        <cid:upload url="http://example.com/upload.php" useMetas="File-name" returnMetas="Public-url" required="true"/>
26
    </cid:process>
27
    <!--
28
      The second part of the manifest is dedicated to the enabled authentication
29
      methods.
30
    -->
31
32
    <!--
33
      The last part of the manifest is dedicated to the transport declaration.
34
      In this example, the transport is a single HTTP request. The properties
35
      attribute defines how the metadata should be sent.
36
      The returned properties must be inserted in a single JSON object in the
37
      body of the HTTP response.
38
     -->
39
    <cid:transports>
40
        <cid:webTransport>
41
            <cid:authentications>
42
                <cid:basicHttp/>
43
            </cid:authentications>
44
            <cid:webUpload>
45
                <cid:request method="GET" properties="header queryString"/>
46
                <cid:request method="PUT" properties="header queryString"/>
47
                <cid:request method="POST" properties="header queryString"/>
48
                <cid:request method="POST;multipart/form-data" properties="header queryString post"/>
49
            </cid:webUpload>
50
        </cid:webTransport>
51
    </cid:transports>
52
</cid:manifest>

The process step by step⚓

Procedure

  1. Manifest exposition

    The server must expose the XML manifest to an accessible URL. For example, at http://example.com/manifest.xml.

  2. Download the manifest

    In order to understand the process, a client must download the server manifest and analyze it.

    Download the manifest

  3. Single upload

    The client can now execute the defined step. In this case, the client must send the file in a single HTTP request following one of the valid transport descriptions of the manifest.

    For example, it could send the file in the body of a PUT request. The File-name metadata could be sent in the header of the request. The body of the server response must be a JSON object containing the returned metadata: Public-url.

    Content upload