Skip to content

Introduction

The REST Services, distributed as part of the SAP Cloud Platform Mobile Services, enables standard HTTP client applications running in any platform to leverage mobile platform for security and push features.

Build client applications using third-party developer tools (JavaScript framework and helper libraries), native client libraries, or the libraries provided by the platform OData SDK (iOS and Android platforms only). The mobile platform enables you to manage and monitor the applications, and provides support for native push notification: Apple Push Notification service (APNS), BlackBerry Internet/Enterprise Service (BIS/BES), Firebase Cloud Messaging (FCM), Windows Notification Service (WNS), or Microsoft Push Notification Service (MPNS).

Application developers must first register an application connection using the REST client and provide the device information, such as device type, password capability, and so on. Once registered, an application can retrieve and update the application connection settings through the REST API. You can enable or disable the push notification only after registering.

Note

You can delete an application connection using the REST API, as long as the application is not in use. Any data that is stored in the custom string of the application connection properties is lost.

During initialization, a client application can download resources (metadata files, multimedia files, and so on), using the resource bundles service. After downloading resources, the application can access OData-compatible data sources through the proxy service, and receive native push notifications triggered by SAP Gateway if push properties are configured and enabled.

This development approach supports:

  • Registration (creating an application connection)
  • Authentication
  • Native push notification
  • Usage reporting

Cloud solutions do not have a Product Availability Matrix (PAM). For more information about cloud solution product versions contact an SAP representative.

Error Codes and Message Formats

The server returns different formats for error codes and messages according to different "Accept" values in request headers.

Accept Header and Data Format

Type and Format Accept Header Values Sample Response Body
XML application/xml, application/xhtml+xml, application/atom+xml <html\><head\><title\>"message string"</title</head\><body\><h1\>"error code" - "error string".</h1\>"<p\><b\>message string</b\> <u\>error string</u\></p\><p\><b\>description</b\> <u\>error message</u\></p\><h3\>"text string"</h3\></body\></html>
JSON application/json, text/json { "error": {"code": "403", "message": {"lang": "en-US", "value": "some specific error text string" } } }
TEXT text/html, text/plain "some specific error text string"

Note

If the Accept header does not include any of these data types, the response body is null.

Retrieve Changed Settings and Connections Metadata

You can retrieve only the changed settings and connections metadata.

To retrieve changed application settings information, issue a GET request to this URL:

URL: https://<mobile services host>/odata/applications/<service version>/<appid>/Connections(‘<appcid>’)?If-None-Match=”${ETag}”

HTTP Method: GET

Parameter Type Description
<appid> Mandatory ID that uniquely identifies an application
<service version> Mandatory v1 onwards

The ${ETag} part of the URL is a version identifier that is included in the response of the GET method. If the ETag value of the current application settings is the same as the value in the request, a status code 304 without a response body is returned to the client to indicate that there are no application setting changes.

HTTP Headers and Cookies

Use HTTP headers and cookies to retrieve application connection information.

Note

In the current platform versions, applications should adopt the header format X-SMP-XXX. To maintain backward compatibility, applications built in earlier versions can continue to use the header format X-SUP-XXX. However, these headers will be removed from future releases, and you should update your applications to use the X-SMP-XXX header format.


Last update: August 12, 2020