API

Introduction to REST APIs

Composer Pro enables you to build apps on multiple platforms such as iOS, Android and Web. Most apps need some way to store data when the app is not running. The data can be stored on the device itself or in an external backend, accessible over the Internet. A common architecture for internet services is a frontend - backend model, in which an app acts as the frontend handling user interactions, while a backend stores and processes data. As it is typical that a frontend (or multiple frontends) will use a different technology stack from that of the backend, there needs be an easy standard way to communicate between the two. This communication in today's applications is typically achieved through the use of REST APIs.

In more detail, what happens is that an app can make a HTTP request to a remote REST API, which then processes the request and as a response returns data. The Data is typically returned in the reader-friendly JSON format.
Here is an example of a JSON data response:

{
  "name": "Justin",
  "lastname": "Oliver",
  "salary": 3400,
  "married": true,

  "phoneNumbers": [
    {
      "type": "home",
      "number": "1111 0000"
    }
  ],

  "email": "justin.oliver@company.json"
}

Apps, such as ones you build with Composer Pro, can access this data after fetching it from an API, and they can also send data back to an API. This is the basis for how all integrations with Composer apps work.

Rest API as a data resource

A REST API direct integration type data resource essentially tells Composer how a specific, JSON-format HTTP REST API can be accessed. It defines things like a base URL, headers, query parameters, available methods, schemas and so on. You can create new external data resources and edit existing ones via the Data button in the top toolbar. Prepackaged external data resource configurations are called connectors, and can be installed into your app via the Marketplace. The resource configuration is split into base configuration and method configurations for GET collection, GET record, POST, PUT/PATCH and DELETE.

Base configuration

Resource ID

This is the unique ID for the resource in your app. Good convention is to have the ID be camel case with an initial capital letter, e.g. SalesforceLeads.

Short description

A short description of this resource, shown if this resource is published in the marketplace.

Resource URL

This is the base URL shared between all methods. For example, if the path to getting a single Salesforce lead would be https://api.salesforce.com/v2/leads/1234, where 1234 is the lead ID, your base URL would be https://api.salesforce.com/v2/leads/. Base URL should always be configured with a trailing slash.

Path variables

Path variables are used to make parts of the URL dynamic. A path variable must always be linked to the base URL by including it inside curly braces at the appropriate place in the URL. For example, to make the v2 part of the Salesforce API URL above dynamic, you would change the base URL to https://api.salesforce.com/{apiVersion}/leads and then add a path variable apiVersion . Path variables are always dynamic – if you wanted to set a static path variable, you should just write the value in the URL itself.

Headers

HTTP headers to be included in every API call made to this external resource.

Query parameters

Query parameters to be included in every API call made to this external resource.

Method configuration

You can configure each method for your RESTful resource separately. Switch between methods via the left panel.

Enabling a method

Initially, all methods are disabled. To enable a method, toggle the switch near the upper-right corner of the screen.

Relative path

This is the relative part of the URL for the current method that will be appended to the base URL when the method is called. For example, for a traditional RESTful resource, the relative path for a GET record method would be just the record ID as a path variable, i.e. {id}.

Response key

The JSON response from an API might include the actual data we are interested in inside a sub-key of the main response object. Response key defines this sub-key as a dot-separated path.

For example, if our JSON response for a Salesforce lead was something like:

{
  "data": {
    "lead": {
      // actual lead data here
    }
  }
}    

We would then define our response key to be data.lead.

Path variables

Path variables work just like in the base configuration, they just target the Relative path instead of the Base URL. For example, the GET record method would likely have a id path variable.

Headers

Extra HTTP headers to be included whenever the current method is called.

Query parameters

Extra query parameters to be included whenever the current method is called. For example, a search or limit query parameter would only make sense when configured exclusively for the GET collection method

Testing methods

Methods can be tested via the Test tab. After getting a successful response, you can auto-detect and set the method schema from the response with the Set schema from response button.

Method schemas

The Schema tab lets you configure schemas for the specific method.

Publishing a data resource configuration to the Marketplace

You can publish a data resource configuration in the Marketplace, which enables you to install it into other apps or share it with others. In the data configurator, click the three-dot icon on the far right side of the data resource list item and select Publish in Marketplace.

To install the data resource in another app, simply search for it via the Marketplace, making sure to select the Data tab first.

Additional video resources