RapidData

What is RapidData?

A common problem that our customers face is how to expose their enterprise applications to mobile use cases, and do so without developing and deploying complex APIs. This guide walks you through Kinvey's RapidData feature, which makes your enterprise applications mobile-ready by connecting them to Kinvey without needing any code.

RapidData is a business and enterprise level feature.

Connector for DataDirect

Overview

The RapidData connector for DataDirect allows you to connect Kinvey to any datastore to which you have a data source already configured in DataDirect.

To create a DataDirect Connector, go to Service Catalog->Add a Service and select DataDirect.

New DLC

Scroll down and fill out the configuration settings:

  • Service Name (e.g. myDataDirectService).
  • Description - optional description.
  • Authentication - Enter your DataDirect username and password.

Creating Service Objects

To allow access to specific data in your system, you need to create a Service Object. A Service Object is a generic term for data objects or records on a remote system that Kinvey can interact with - in this case DataDirect data source. To create a Service Object, go to the Service Catalog and click the gear icon on the service card. Choose Service Objects in the left menu.

Service Object

  • In the first box, you can provide a name for the Service Object. This name is used by your mobile developer to reference the Endpoint within Kinvey. You can make the name match the Endpoint name, or provide a more user-friendly name. In the screenshot above, the Endpoint is 'Employees', but the Service Object name is 'people'.

  • The Endpoint is of the format /<datasourceName>/<entityInstance>

  • Primary key name and type - the name of the property that uniquely identifies the resource, and whether it’s a number (int) or string.

  • Flipping the toggles under Supported Operations enables the respective operation. Any requests sent to Kinvey for operations not enabled here will get an error (405 METHOD NOT ALLOWED). If you want a "read-only" access to your system, only enable the get operations. Enabling getByQuery makes it possible for your mobile developers to submit queries using our native mobile libraries, which is a capability very central to building a great mobile application.

  • Under field mapping, you can limit the fields exposed. By default, all fields are exposed, but you can restrict that by clicking the 'X' on that row. Great mobile apps are streamlined around a specific use case, and it's likely that you would only need a subset of those fields.

The only required field on the Kinvey side is _id. It serves as a primary key. You need to map your primary key to the Kinvey _id field.

  • Nested fields are supported. To map a nested field, use a dot notation, e.g. name.firstname. Note that if your system has nested fields, the discovery feature only detects the top level. However you can still manually add the mapping. For example location.city can map to City on the Kinvey side. There is no limit on the nesting depth.
  • Once you hit Add Service Object your service object is created and your SObject is accessible.

Accessing Service Objects

To make a Service Object accessible from a mobile application, it needs to be mapped to a collection. This is normally something that a mobile developer does as part of developing an app, but it is recommended that the backend app owner does it as well in order to verify the flow of data.

Create a collection (Collections->Add Collection).

  • Provide a name for this collection. The name must match the Service Object name you mapped. The matched name serves as mapping between the collection and the Service Object.
  • Select the Use a Data Service, option.
  • Select the Service from the list below. Then select your Service Object from the dropdown.
  • Click confirm.

It is important that the collection name and the Service Object name match.

To verify each Service Object you exposed, create one collection per Service Object.

To interact with your data, make a request to the mapped Kinvey Collection using the API Console. (Left Nav->API Console). Complete the URL box with the name of your collection and hit Send Request to see a data panel below appear with your data in it. If updates or deletes are allowed, select the appropriate verb and pass the right request body if needed.

Connector for SharePoint

To create a SharePoint Connector, go to Service Catalog->Add a Service and select SharePoint.

New DLC

Scroll down and fill out the configuration settings:

  • Name (e.g. mysharepoint).
  • SharePoint Version - select among the list of currently supported versions. Note that if your instance is hosted on-premises and inaccessible from the Internet, you need to utilize our Secure Gateway to provide access to your on-premises systems. Contact sales if you would like to learn more about this.
  • Host name - this is the hostname of your SharePoint instance.
  • Site - leave blank to utilize the default site. To use a sub-site, enter the subsite name (e.g. ‘MySubSite’).
  • Encryption - check that box for most installations. If your on-premise Sharepoint Instance does not support TLS, leave this unchecked.
  • Authentication - select Service Account and enter your credentials.

Creating Service Objects

To allow access to specific data in your system, you need to create a Service Object. A Service Object is a generic term for data objects or records on a remote system that Kinvey can interact with - in this case SharePoint Lists. To create a Service Object, go to the Service Catalog and click the gear icon on the service card. Choose Service Objects in the left menu.

RapidData for SharePoint allows you to work with SharePoint Lists. Support for other objects, such as Files, is on the roadmap.

Service Objects can be created manually, but RapidData comes with a convenient tool that auto-discovers all SharePoint Lists available on your instance. Click Discover to make Kinvey query your instance for all available Lists. This might take a few seconds, depending on how many you have. Find the List you want to expose and click on View. For this example, we show a List called "Employee".

Service Object

  • In the first box, you can provide a name for the Service Object. This name is used by your mobile developer to reference the SharePoint List within Kinvey. You can make the name match the List name, or provide a more user-friendly name.

  • Flipping the toggles under Supported Operations enables the respective operation. Any requests sent to Kinvey for operations not enabled here will get an error (405 METHOD NOT ALLOWED). If you want a "read-only" access to your system, only enable the get operations. Enabling getByQuery makes it possible for your mobile developers to submit queries using our native mobile libraries, which is a capability very central to building a great mobile application.

  • Under field mapping, you can limit the fields exposed. By default, all fields are exposed, but you can restrict that by clicking the 'X' on that row. Great mobile apps are streamlined around a specific use case, and it's likely that you would only need a subset of those fields.

The only required field on the Kinvey side is _id. It serves as a primary key. You need to map your primary key to the Kinvey _id field.

  • Nested fields are supported. To map a nested field, use a dot notation, e.g. name.firstname. Note that if your system has nested fields, the discovery feature only detects the top level. However you can still manually add the mapping. For example location.city can map to City on the Kinvey side. There is no limit on the nesting depth.
  • Once you hit Add Service Object your service object is created and your SharePoint List is accessible.

Accessing Service Objects

To make a Service Object accessible from a mobile application, it needs to be mapped to a collection. This is normally something that a mobile developer does as part of developing an app, but it is recommended that the backend app owner does it as well in order to verify the flow of data.

Create a collection (Collections->Add Collection).

  • Provide a name for this collection. The name must match the Service Object name you mapped. The matched name serves as mapping between the collection and the Service Object.
  • Select the Use a Data Service, option.
  • Select the Service from the list below. Then select your Service Object from the dropdown.
  • Click confirm.

It is important that the collection name and the Service Object name match.

To verify each Service Object you exposed, create one collection per Service Object.

To interact with your data, make a request to the mapped Kinvey Collection using the API Console. (Left Nav->API Console). Complete the URL box with the name of your collection and hit Send Request to see a data panel below appear with your data in it. If updates or deletes are allowed, select the appropriate verb and pass the right request body if needed.

Connector for Microsoft SQL Server

To create a Microsoft SQL Server Connector, Service Catalog->Add a Service and select MS SQL.

New DLC

Scroll down and fill out the configuration settings:

  • Name (e.g. mysqlserver).
  • SQL Server Version - select among the list of currently supported versions. Note that if your instance is hosted on-premises and inaccessible from the Internet, you need to utilize our Secure Gateway to provide access to your on-premises systems. Contact sales if you would like to learn more about this.
  • Host name - this is the hostname of your SQL Server instance.
  • Database Name - the name of the database you want to use.
  • Authentication - select Service Account or Windows Service Account and enter your credentials.

Creating Service Objects

To allow access to specific data in your system, you need to create a Service Object. A Service Object is a generic term for data objects or records on a remote system that Kinvey can interact with - in this case SharePoint Lists. To create a Service Object, go to the Service Catalog and click the gear icon on the service card. Choose Service Objects in the left menu.

Service Objects can be created manually, but RapidData comes with a convenient tool that auto-discovers all SQL Objects available on your instance. Click Discover to make Kinvey query your instance. This might take a few seconds, depending on how many you have. Find the List you want to expose and click on View. For this example, we show a Table called "people".

Service Object

  • In the first box, you can provide a name for the Service Object. This name is used by your mobile developer to reference the SQL Object within Kinvey. You can make the name match the Table or View name, or provide a more user-friendly name. In the screenshot above, the Table is people, but the Service Object name is "Contacts".

  • Flipping the toggles under Supported Operations enables the respective operation. Any requests sent to Kinvey for operations not enabled here will get an error (405 METHOD NOT ALLOWED). If you want a "read-only" access to your system, only enable the get operations. Enabling getByQuery makes it possible for your mobile developers to submit queries using our native mobile libraries, which is a capability very central to building a great mobile application.

  • Under field mapping, you can limit the fields exposed. By default, all fields are exposed, but you can restrict that by clicking the 'X' on that row. Great mobile apps are streamlined around a specific use case, and it's likely that you would only need a subset of those fields.

The only required field on the Kinvey side is _id. It serves as a primary key. You need to map your primary key to the Kinvey _id field.

  • Nested fields are supported. To map a nested field, use a dot notation, e.g. name.firstname. Note that if your system has nested fields, the discovery feature only detects the top level. However you can still manually add the mapping. For example location.city can map to City on the Kinvey side. There is no limit on the nesting depth.
  • Once you hit Add Service Object your service object is created and your SQL Object is accessible.

Accessing Service Objects

To make a Service Object accessible from a mobile application, it needs to be mapped to a collection. This is normally something that a mobile developer does as part of developing an app, but it is recommended that the backend app owner does it as well in order to verify the flow of data.

Create a collection (Collections->Add Collection).

  • Provide a name for this collection. The name must match the Service Object name you mapped. The matched name serves as mapping between the collection and the Service Object.
  • Select the Use a Data Service, option.
  • Select the Service from the list below. Then select your Service Object from the dropdown.
  • Click confirm.

It is important that the collection name and the Service Object name match.

To verify each Service Object you exposed, create one collection per Service Object.

To interact with your data, make a request to the mapped Kinvey Collection using the API Console. (Left Nav->API Console). Complete the URL box with the name of your collection and hit Send Request to see a data panel below appear with your data in it. If updates or deletes are allowed, select the appropriate verb and pass the right request body if needed.

Connector for Salesforce

To create a Salesforce Connector, go to Service Catalog->Add a Service and select Salesforce.

New DLC

Scroll down and fill out the configuration settings:

  • Name (e.g. mysalesforce).
  • Host name - this is the hostname of your Salesforce instance.
  • Authentication - select Service Account or Service Account OAuth and enter your credentials.

Creating Service Objects

To allow access to specific data in your system, you need to create a Service Object. A Service Object is a generic term for data objects or records on a remote system that Kinvey can interact with - in this case SharePoint Lists. To create a Service Object, go to the Service Catalog and click the gear icon on the service card. Choose Service Objects in the left menu.

Service Objects can be created manually, but RapidData comes with a convenient tool that auto-discovers all SObjects available on your instance. Click Discover to make Kinvey query your instance. This might take a few seconds, depending on how many you have. Find the List you want to expose and click on View. For this example, we show an SObject called "Contacts".

Service Object

  • In the first box, you can provide a name for the Service Object. This name is used by your mobile developer to reference the SObject within Kinvey. You can make the name match the SObject name, or provide a more user-friendly name.

  • Flipping the toggles under Supported Operations enables the respective operation. Any requests sent to Kinvey for operations not enabled here will get an error (405 METHOD NOT ALLOWED). If you want a "read-only" access to your system, only enable the get operations. Enabling getByQuery makes it possible for your mobile developers to submit queries using our native mobile libraries, which is a capability very central to building a great mobile application.

  • Under field mapping, you can limit the fields exposed. By default, all fields are exposed, but you can restrict that by clicking the 'X' on that row. Great mobile apps are streamlined around a specific use case, and it's likely that you would only need a subset of those fields.

The only required field on the Kinvey side is _id. It serves as a primary key. You need to map your primary key to the Kinvey _id field.

  • Nested fields are supported. To map a nested field, use a dot notation, e.g. name.firstname. Note that if your system has nested fields, the discovery feature only detects the top level. However you can still manually add the mapping. For example location.city can map to City on the Kinvey side. There is no limit on the nesting depth.
  • Once you hit Add Service Object your service object is created and your SObject is accessible.

Accessing Service Objects

To make a Service Object accessible from a mobile application, it needs to be mapped to a collection. This is normally something that a mobile developer does as part of developing an app, but it is recommended that the backend app owner does it as well in order to verify the flow of data.

Create a collection (Collections->Add Collection).

  • Provide a name for this collection. The name must match the Service Object name you mapped. The matched name serves as mapping between the collection and the Service Object.
  • Select the Use a Data Service, option.
  • Select the Service from the list below. Then select your Service Object from the dropdown.
  • Click confirm.

It is important that the collection name and the Service Object name match.

To verify each Service Object you exposed, create one collection per Service Object.

To interact with your data, make a request to the mapped Kinvey Collection using the API Console. (Left Nav->API Console). Complete the URL box with the name of your collection and hit Send Request to see a data panel below appear with your data in it. If updates or deletes are allowed, select the appropriate verb and pass the right request body if needed.

Connector for SAP

To create an SAP Connector, go to Service Catalog->Add a Service and select SAP RFC.

New DLC

Scroll down and fill out the configuration settings:

  • Service Name (e.g. mySAP).
  • Description - optional description.
  • Host - this is the hostname of your SAP instance, for example sap://117.117.17.17
  • sysId, sysNum, Client, Language - contact your SAP administrator if you don't know these.
  • Authentication - select Service Account and enter your credentials.

Creating Service Objects

To allow access to specific data in your system, you need to create a Service Object. A Service Object is a generic term for data objects or records on a remote system that Kinvey can interact with - in this case SharePoint Lists. To create a Service Object, go to the Service Catalog and click the gear icon on the service card. Choose Service Objects in the left menu.

Service Object

  • In the first box, you can provide a name for the Service Object. This name is used by your mobile developer to reference the SObject within Kinvey. You can make the name match the RFC name, or provide a more user-friendly name. In the screenshot above, the RFC is ZRFC_EMPLOYE_DETAILS, but the Service Object name is Employees.

  • Context Root - is the inner element in the RFC response that holds the data resources. Leave blank if the response is the same as the results.

  • Primary key name and type - the name of the property that uniquely identifies the resource, and whether it’s a number (int) or string.

  • Static Input Properties - hard-coded input values into the RFC function that need to be included in every RFC call (i.e. not dynamically set via a query).

  • Flipping the toggles under Supported Operations enables the respective operation. Any requests sent to Kinvey for operations not enabled here will get an error (405 METHOD NOT ALLOWED). If you want a "read-only" access to your system, only enable the get operations. Enabling getByQuery makes it possible for your mobile developers to submit queries using our native mobile libraries, which is a capability very central to building a great mobile application.

  • Under field mapping, you can limit the fields exposed. By default, all fields are exposed, but you can restrict that by clicking the 'X' on that row. Great mobile apps are streamlined around a specific use case, and it's likely that you would only need a subset of those fields.

The only required field on the Kinvey side is _id. It serves as a primary key. You need to map your primary key to the Kinvey _id field.

  • Nested fields are supported. To map a nested field, use a dot notation, e.g. name.firstname. Note that if your system has nested fields, the discovery feature only detects the top level. However you can still manually add the mapping. For example location.city can map to City on the Kinvey side. There is no limit on the nesting depth.
  • Once you hit Add Service Object your service object is created and your RFC is accessible.

Accessing Service Objects

To make a Service Object accessible from a mobile application, it needs to be mapped to a collection. This is normally something that a mobile developer does as part of developing an app, but it is recommended that the backend app owner does it as well in order to verify the flow of data.

Create a collection (Collections->Add Collection).

  • Provide a name for this collection. The name must match the Service Object name you mapped. The matched name serves as mapping between the collection and the Service Object.
  • Select the Use a Data Service, option.
  • Select the Service from the list below. Then select your Service Object from the dropdown.
  • Click confirm.

It is important that the collection name and the Service Object name match.

To verify each Service Object you exposed, create one collection per Service Object.

To interact with your data, make a request to the mapped Kinvey Collection using the API Console. (Left Nav->API Console). Complete the URL box with the name of your collection and hit Send Request to see a data panel below appear with your data in it. If updates or deletes are allowed, select the appropriate verb and pass the right request body if needed.

Connector for REST APIs

Overview

The RapidData connector for REST allows you to connect Kinvey to REST APIs. The configuration defaults used are organized around an assumption that the remote API is RESTful (e.g. it is not just JSON over HTTP). At the same time, given that this is not always the case, there are many options available to override the defaults.

To create a REST Connector, go to Service Catalog->Add a Service and select REST Data.

New DLC

Scroll down and fill out the configuration settings:

  • Service Name (e.g. myRESTConnector).
  • Description - optional description.
  • Host name - the base URL that you are connecting to (e.g https://someApi.com/v1/api/).
  • Headers - any custom headers to be applied to all requests to this REST API. Suitable API keys, or special global static parameters that need to be passed.
  • Query Params - same as above for query params (e.g. ?apikey=YzCwFdbh3cTuVGlvDCI9).
  • Authentication Settings
    • None - no authentication required (common for APIs that just have a static API key).
    • Basic - the credentials (username/password) are passed as a base64 encoded value in the Authorization header.
    • MIC - use a MIC configuration. The options below allow you to choose how the auth token is passed to the API.
      • Credentials Map To Type - pass via a Header, Query String or Body.
      • Credentials Map To Property - the name of the header, query string property, or body property (depending on your choice above) in which the auth token will be stored.
      • Credentials Map To Decode - by default, the token is base64 encoded. Use this option to decode it.
    • OAuth - the credentials are passed as a base64 encoded value in the Authorization header. Credentials include username, password and the token endpoint (the URL to get the token from).
  • Login Options - should be used for APIs that require login before making requests.

    • Login Options Type
      • Maintain Session - log in, retrieve some kind of session token, and use that session token for future logins.
      • Verify Only - verify the credentials before making a data request, without using or storing a separate session token.
      • No Login - no login required prior to making a data request. Note that this does not mean no authentication, just no separate login step.
    • Login Endpoint URI - the full URI for logging in.
    • HTTP Method - the HTTP method to use for logging in.

    The options below are for the Maintain Session type only.

    • Token From Type - choose whether to get the token from a Header, Query String parameter, or Body.
    • Token From Property - the name of the Header, Query String property, or Body property (depending on your choice above) from which the token will be retrieved.
    • Token To Type - choose whether, in subsequent requests, to pass the token in a Header, Query String parameter, or Body.
    • Token To Property - the name of the header, query string property, or body property (depending on your choice above) into which the token will be placed.
    • Login Headers/QueryParams/Body - static values to pass to the login method.

Creating Service Objects

To allow access to specific data in your system, you need to create a Service Object. A Service Object is a generic term for data objects or records on a remote system that Kinvey can interact with - in this case SharePoint Lists. To create a Service Object, go to the Service Catalog and click the gear icon on the service card. Choose Service Objects in the left menu.

Service Object

  • In the first box, you can provide a name for the Service Object. This name is used by your mobile developer to reference the Endpoint within Kinvey. You can make the name match the Endpoint name, or provide a more user-friendly name. In the screenshot above, the Endpoint is 'inspiration-search', but the Service Object name is 'flight-search'.

  • Context Root - optionally allows you to extract nested data from server responses. If the JSON response from your server sends data as a nested property, set the Context Root to that property name. Leave blank if the entire response from your server should be returned to the client without modification. In the example below, the 'resultSet' property contains the data that should be returned to the client and Context Root should be set to 'resultSet':

    {
      someMetadata: '...',
      moreMetadata: '...',
      resultSet:  [{<object1>},{<object2>},...{<objectN>}]
    }
  • Primary key name and type - the name of the property that uniquely identifies the resource, and whether it’s a number (int) or string.

  • Query Mapping - allows to customize how Kinvey-side queries are passed to the remote REST API.

  • Static Headers and Static Query Params - allows you to add any custom, static headers/query string values to be included in every request to the API. Tokens are also supported.

  • Flipping the toggles under Supported Operations enables the respective operation. Any requests sent to Kinvey for operations not enabled here will get an error (405 METHOD NOT ALLOWED). If you want a "read-only" access to your system, only enable the get operations. Enabling getByQuery makes it possible for your mobile developers to submit queries using our native mobile libraries, which is a capability very central to building a great mobile application.

  • Under field mapping, you can limit the fields exposed. By default, all fields are exposed, but you can restrict that by clicking the 'X' on that row. Great mobile apps are streamlined around a specific use case, and it's likely that you would only need a subset of those fields.

The only required field on the Kinvey side is _id. It serves as a primary key. You need to map your primary key to the Kinvey _id field.

  • Nested fields are supported. To map a nested field, use a dot notation, e.g. name.firstname. Note that if your system has nested fields, the discovery feature only detects the top level. However you can still manually add the mapping. For example location.city can map to City on the Kinvey side. There is no limit on the nesting depth.
  • Once you hit Add Service Object your service object is created and your SObject is accessible.

Accessing Service Objects

To make a Service Object accessible from a mobile application, it needs to be mapped to a collection. This is normally something that a mobile developer does as part of developing an app, but it is recommended that the backend app owner does it as well in order to verify the flow of data.

Create a collection (Collections->Add Collection).

  • Provide a name for this collection. The name must match the Service Object name you mapped. The matched name serves as mapping between the collection and the Service Object.
  • Select the Use a Data Service, option.
  • Select the Service from the list below. Then select your Service Object from the dropdown.
  • Click confirm.

It is important that the collection name and the Service Object name match.

To verify each Service Object you exposed, create one collection per Service Object.

To interact with your data, make a request to the mapped Kinvey Collection using the API Console. (Left Nav->API Console). Complete the URL box with the name of your collection and hit Send Request to see a data panel below appear with your data in it. If updates or deletes are allowed, select the appropriate verb and pass the right request body if needed.

Configuring REST endpoints

There are different ways that a REST connector can be configured and API calls can be made dynamic.

Passing parameters as part of the request

  • Header - HTTP headers allow the user to pass additional information with the request to the REST endpoint. You can set the Query Mapping field to Header to map kinvey parameters to header fields that the REST endpoint expects. For example, if you want to set a header to the REST endpoint called someKey with a value of someValue, you can do it with the following call.

    /appdata/:appKey/:collectionName/?query={"someKey":"someValue"}
  • Body - You can set the Query Mapping field to Body to map kinvey parameters to the request body. To pass information in the body to the REST endpoint, you can attach it to the query property of the KCS request.

    /appdata/:appKey/:collectionName/?query={"someKey":"someValue"}

    This will send {"someKey":"someValue"} in the body to the REST endpoint.

  • Query String - You can set the Query Mapping field to query to map kinvey parameters to the request query params. To pass some information in querystring to REST endpoint, you can attach it to the query property of the KCS request. The API request

    /appdata/:appKey/:collectionName/?query={"someKey":"someValue", "anotherKey":"anotherValue"}

    results in the following call to the REST endpoint:

    myRestApi/myEndpoint/?someKey=someValue&anotherKey=anotherValue

Embedding dynamic tokens in the endpoint

  • Setting Query Mapping to Dynamic Endpoint Token

    You can use dynamic endpoint tokens to map the query, skip, limit, fields, and sort properties of the query object to other parts of the URL.These endpoint tokens are structured as:

    • query property

      The query property can be mapped using a token like

      <endpoint>/:queryToken{:key<assignment>:value;<delimiter>}

      For example, the configured endpoint can be

      myEndpoint/:queryToken{:key=:value;,}

      The API request

      /appdata/:appKey/:collectionName/?query={"key1": "value1", "key2":"value2"}

      results in the following call to the REST endpoint:

      /myRestApi/myEndpoint/key1=value1,key2=value2
    • skip property

      The skip property can be mapped using a token like

      <endpoint>/:skipToken

      The API request

      /appdata/:appKey/collectionName/?skip=5

      results in the following call to the REST endpoint

      myRestApi/myEndpoint/5
    • limit property

      The limit property can be mapped using a token like

      <endpoint>/:limitToken

      The API request

      /appdata/:appKey/collectionName/?limit=10

      results in the following call to the REST endpoint

      myRestApi/myEndpoint/10
    • fields property

      The fields property can be mapped using a token like

      /<endpoint>/:fieldsToken{<delimiter>}

      For example, the endpoint can be configured as

      myEndpoint/:fieldsToken{;}

      The API request

      /appdata/<appid>/myRestCollection/?fields=['f1','f2,'f3']

      results in the following call to the REST endpoint

      /myRestApi/myEndpoint/f1;f2;f3
    • sort property

      The sort property can be mapped using a token like

      <endpoint>/:sortToken{:key<assignment>;<asc>;<desc>;<delimiter>}
  • Setting Query Mapping to Tokens

    You can map query properties to parts of the url at runtime using endpoint tokens. For example, you can define the endpoint such as

    myEndpoint/:state/:city

    The API request

    /appdata/:appKey/:collectionName/?query={“state”:”MA", “city”:”Boston”}

    results in the following call to the REST endpoint

    /myRestApi/myEndpoint/MA/Boston
  • Using Kinvey Request tokens

    • You can embed the username in the endpoint by defining the endpoint as
      myEndpoint/:_kinveyRequest.userName
      For example, if this username is JohnDoe, this would result in the API call
      myRestApi/myEndpoint/JohnDoe
    • Similarly, you can embed the user id in the endpoint configuration as
      myRestApi/myEndpoint/:_kinveyRequest.userId
    • Also, you can embed the client app version that is present in the X-Kinvey-Client-App-Version header by
      myRestApi/myEndpoint/:_kinveyRequest.clientAppVersion
    • Custom Request Properties

      The object defined in the X-Kinvey-Custom-Request-Properties header can be used to create a dynamic endpoint as well. For example, if the endpoint is defined as:

       myEndpoint/:kinveyRequest.customRequestProperties.someKey

      and the X-Kinvey-Client-App-Version is set to {"someKey:"someValue"}, the resultant call to the following REST endpoint

       /myRestApi/myEndpoint/someValue

Kinvey Request Tokens can be used for all types of API calls, but the others can be used only for query related calls (getByQuery, deleteByQuery, and getCountByQuery).

Got a question?