Example 2: Retrieve the public URL of a remote content [Discover CID]

Example 2: Retrieve the public URL of a remote content

In this case, the server handles files (like an ECM platform). A client needs the unique URL of a remote content. The CID process allows a user to select a content and defines how the client can retrieve its Public-url.

Server manifest⚓

<?xml version="1.0" encoding="UTF-8"?>
<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 ">
    <cid:process is="http://schema.org/FindAction http://schema.org/CheckAction">
        <cid:label xml:lang="en">Public URL retrieving</cid:label>
        <cid:doc xml:lang="en">Browse your online contents to retrieve a public URL.</cid:doc>
        <cid:meta name="Public-url" is="http://schema.org/url"/>
        <!-- The process is composed by a single interaction step. -->
        <cid:interact url="http://.." returnMetas="Public-url" required="true"/>
    </cid:process>
    <!-- 
    The web interaction begins with a single HTTP request and ends with a message event 	
    (http://www.w3.org/TR/webmessaging) containing a cidInteraction property stored in the data
    part of the event. This property must be set to "ended" (in case of regular end of the step)
    or "aborted" (in case of step cancelled by the user). The client must instantiate a web frame
    and fill it with the result of the first request. It gets the returned metadata in the data
    part of the message event. In this example, the server does not furnish any authentication scheme.
    It could handle a web authentication in the frame or let a public access to the platform. 
    -->
    <cid:transports>
        <cid:webTransport>
            <cid:authentications/>
            <cid:webInteract>
                <cid:request method="GET" properties="header queryString"/>
                <cid:request method="POST;application/x-www-form-urlencoded" properties="queryString header post"/>
                <cid:request method="POST;multipart/form-data" properties="header queryString post"/>
            </cid:webInteract>
        </cid:webTransport>
    </cid:transports>
</cid:manifest>

<?xml version="1.0" encoding="UTF-8"?>
<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 ">
    <cid:process is="http://schema.org/FindAction http://schema.org/CheckAction">
        <cid:label xml:lang="en">Public URL retrieving</cid:label>
        <cid:doc xml:lang="en">Browse your online contents to retrieve a public URL.</cid:doc>
        <cid:meta name="Public-url" is="http://schema.org/url"/>
        <!-- The process is composed by a single interaction step. -->
        <cid:interact url="http://.." returnMetas="Public-url" required="true"/>
    </cid:process>
    <!-- 
    The web interaction begins with a single HTTP request and ends with a message event 	
    (http://www.w3.org/TR/webmessaging) containing a cidInteraction property stored in the data
    part of the event. This property must be set to "ended" (in case of regular end of the step)
    or "aborted" (in case of step cancelled by the user). The client must instantiate a web frame
    and fill it with the result of the first request. It gets the returned metadata in the data
    part of the message event. In this example, the server does not furnish any authentication scheme.
    It could handle a web authentication in the frame or let a public access to the platform. 
    -->
    <cid:transports>
        <cid:webTransport>
            <cid:authentications/>
            <cid:webInteract>
                <cid:request method="GET" properties="header queryString"/>
                <cid:request method="POST;application/x-www-form-urlencoded" properties="queryString header post"/>
                <cid:request method="POST;multipart/form-data" properties="header queryString post"/>
            </cid:webInteract>
        </cid:webTransport>
    </cid:transports>
</cid:manifest>

The process step by step⚓

Procedure

Manifest exposition
The server must expose the XML manifest to an accessible URL. For example, at http://example.com/manifest.xml.
Download the manifest
In order to understand the process, a client must download the server manifest and analyze it.
Download the manifest
Direct interaction
The client can now execute the defined step. In this case, the client must send a single HTTP request and show the result in a web frame. The user should then interact directly with the server using the frame.
Direct interaction
At the end of the process, the web page of the frame must post a message event throught the message API. The client must catch this event and read the endInteraction property store in the data part of the event. This property must be set to ended when the interaction is regularly closed or aborted when the user cancelled the process during the interaction. In case of regularly ended interaction, the returned metadata documented in this step are also stored: the Public-url in this case.