Data Sources Declarative API Interface

This article explains how to use the declarative API interface to manage Data Sources. For a high-level overview of the declarative API interface, please refer to the declarative API interface documentation.

Managing Data Sources

The declarative API interface allows you to manage all Data Source entities at once, including their physical model. The declarative API interface for Data Sources uses the following endpoint:

  • /api/v1/layout/dataSources

The default hostname for the application endpoint is determined by which edition of GoodData.CN you use:

  • GoodData.CN
    https://<organization-hostname>/api/v1/layout/dataSources
  • GoodData.CN Community Edition
    http://localhost:<port>/api/v1/layout/dataSources

Where:

  • <organization-hostname>
    Specifies the hostname for your organization with GoodData.CN. For example gooddata.com.
  • <port>
    Specifies the port to access your installation of GoodData.CN Community Edition. The default port is 3000.

Write Operations

Data Source Passwords

The passwords for Data Source users can be stored using the declarative API interface, but they cannot be retrieved using the declarative API interface.

Example Requests

The examples in this section are not meant to be used without modification. Please modify the examples to match the requirements of your site before using them.

Create A Backup Of All Data Sources

The following example retrieves the entire declarative layout of your Data Sources and stores the output in a JSON file named data-sources-layout.json. The passwords are not retrieved as it is not possible to retrieve passwords through the API. Refer to data source passwords for more information.

curl -H "Authorization: Bearer YWRtaW46Ym9vdHN0cmFwOmFkbWluMTIz" \
  $HOSTNAME/api/v1/layout/dataSources > data-sources-layout.json

Restore All Data Sources

The following example replaces the current Data Source declarative layout with that of a previously retrieved declarative layout. If the previously retrieved declarative layout has not been updated to include the Data Source passwords, the Data Source passwords must be inserted afterwards.

curl -H "Authorization: Bearer YWRtaW46Ym9vdHN0cmFwOmFkbWluMTIz" \
  -H "Content-Type: application/json" \
  -X PUT \
  $HOSTNAME/api/v1/layout/dataSources -d @data-sources-layout.json

Data Source Declarative Layout Document

The following example shows a truncated physical model for the Data Sources declarative layout. The password is replaced with a dummy value.

{
  "dataSources": [
    {
      "id": "pg_local_docker-demo",
      "name": "pg_local_docker-demo",
      "pdm": {
        "tables": [
          {
            "columns": [
              {
                "dataType": "STRING",
                "isPrimaryKey": false,
                "name": "category"
              },
              {
                "dataType": "INT",
                "isPrimaryKey": true,
                "name": "product_id"
              },
              {
                "dataType": "STRING",
                "isPrimaryKey": false,
                "name": "product_name"
              }
            ],
            "id": "products",
            "path": [
              "products"
            ],
            "type": "VIEW"
          }
        ]
      },
      "schema": "demo",
      "type": "POSTGRESQL",
      "url": "jdbc:postgresql://postgres:5432/tiger",
      "username": "postgres",
      "password": "<password>"
    } 
  ]
}

You can also issue a PUT request to the data sources declarative API endpoint with an empty physical model.

{
  "dataSources": [
    {
      "id": "pg_local_docker-demo",
      "name": "pg_local_docker-demo",
      "pdm": {
        "tables": []
      },
      "schema": "demo",
      "type": "POSTGRESQL",
      "url": "jdbc:postgresql://postgres:5432/tiger",
      "username": "postgres",
      "password": "<password>"
    }
  ]
}