Resource Representation

Resource Representation

In data exchange flows, the data space connector should be able to communicate with the participant's application or data source to push or pull a specific resource under certain conditions. Resource representations are the information that allow just that. It is an extension to the Data / Software resource data model composing a participant's offering catalogue and it contains the needed metadata to allow the connector to know where and how to pull or push data from / to a participant application.

The catalogue allows to inform this metadata on the resources that are registered to the catalogue. This goes for both data resources and service resources.

Resource representation for data

When specifying representation metadata for data resources, this is usually done by data providers to define how their own connector should access this specific resource. The catalogue allows to inform :

• The URL the connector should call to get the data
• What type of source it should be
• The credentials it should use to communicate with the data provider's application

Resource representation for services

For service providers / data consumers, resource representation metadata should be informed for the proposed services on data processing they register in the catalogue. The configuration is very similar and the fields to inform are globally the same as for data representations. Some catalogues may ask for more or less information depending on the needs of the catalogue.

Variables used in representation

In the URL of the representation, you can include variables enclosed in curly braces "{}". These variables will be interpreted by the connector and replaced at runtime with data from your user/userIdentifier.

userId

Including {userId} in the URL will replace it with the identifier/internalID of your user (on the connector side) or userIdentifier (on the consent side) at runtime.

url

Including {url} in the URL will replace it with the URL field added to your user (on the connector side) at runtime.

Note

These configuration processes are to be done on the catalogue you are using and are not meant to be done within the connector itself. The only configuration needed from the connector on this part is the creation of the credentials, which will generate an id to inform on the catalogue.

Proxy Support

The connector can manage proxy settings to allow connections through a proxy server if required for a resource.

Configuring Proxy Settings on a resource

The configuration is made in the catalog on the resource settings. You can specify the following parameters:

• Proxy Host: The hostname or IP address of the proxy server.
• Proxy Port: The port number on which the proxy server is listening.
• Proxy Credential: (Optional) The credential id registered on your connector.

Credential for Proxy Authentication

If your proxy server requires authentication, you can create a credential in your connector with the necessary username and password. Then, reference this credential in the resource settings under "Credential".

This setup is similar to how credentials are associated to resource endpoints as explained in Credentials.

Example

Here is an example of how to configure the credential to be correctly used by the proxy as username and password

POST /private/credential

{
  "type": "proxy",
  "key": "your-proxy-username",
  "value": "your-proxy-password"
}

response:

{
  "timestamp": 1764249993506,
  "code": 201,
  "content": {
    "_id": "69285189d18bf784ee2c1435",
    "key": "your-proxy-username",
    "value": "your-proxy-password",
    "type": "proxy",
    "__v": 0
  }
}

Then, in the resource settings, you can specify the _id of the created credential.

---

>> Credentials