Introduction¶
The REST Services, distributed as part of the SAP 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 | Version 1 and later |
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.