Test Custom APIs

In Oracle Mobile Hub you can test your custom APIs before they are deployed by using mock data. You can also test your REST connectors using the test page that supports two modes: Standard testing, and Advanced testing.

Test an Oracle Mobile Hub Custom API

To test your custom API directly from Oracle Mobile Hub:

Sign in to Oracle Mobile Hub.
Click the menu icon, and then expand Development and click Backends.
Select your mobile backend and click Open.
Click Settings in the left navigation bar.
Copy the URL from the SSO Token Endpoint located under Environment URLs.
Paste the copied URL into a web browser window, but don’t press the Enter key.
Copy your client ID located under the OAuth Consumer section.
Add a query string parameter to the SSO token endpoint URL you pasted in your web browser in the form?clientID=[YourClientID], and then press the Enter key. An example of the URL looks like this:
```
https://<YourSSOTokenEndpointURL>?clientID=<yourClientID>
```
The browser will show you a Single Sign-On OAuth Token.
In your mobile backend window, click the APIs page located in the left navigation. The browser will change from the Settings page to the APIs page.
Click Select APIs.
Click the API name that you want to test. A new page opens that shows the API endpoints on the left navigation as well as the Request and Response tabs.
Click on the endpoint that you want to test.
Under the Authentication section, select Single Sign-on Token from the Authentication Method.
Copy your SSO OAuth Token and paste it in the Single Sign-On Token field.
Click Test Endpoint. If everything is correct, the server responds with status 200, and you should see the JSON data in the response.

Test API Endpoints Using Mock Data

You can provide mock data in your request and response message bodies during the design phase of your API configuration. This lets you examine the context of each call without having to use real-time data or interact with a real-time service. For example, to test whether your code correctly handles an invalid ID, you can add an example in your request body with mock data that contains an invalid ID. When you finish the test, you can replace the example with other code to test some other aspect of the method.

In the FixItFast example, the mock data in the response body lets you verify if the correct customer information is being returned. Here’s an example of mock data that the service developer could create for the response body of the POST operation of the contact resource in the FixItFast example:

{
 "id": 20934,
 "title": "Lynn's Leaking Water Heater",
       "contact": {
       "name": "Lynn Adams",
       "street": "45 O'Connor Street",
       "city": "Ottawa",
       "postalcode": "ala1a1"
       "username":"johneta"
       }
 "status": "new",
 "driveTime": 30,
 "priority": "high",
 "createdon": "2015-04-23 18:12:03 EDT"
}

When you create a custom API, a mock implementation is created automatically. The mock implementation lets you invoke the API from your mobile application before you implement the custom code. This lets you develop and test the mobile applications and the custom code simultaneously. If you’re satisfied with the configuration, you can add a real implementation.

Until you create your first implementation, the default implementation is the mock implementation. After you create a real implementation, it becomes the default implementation for the API.

Click the Implementations navigation link to upload an implementation or to see any existing implementations. You can change the default implementation on the Implementations page. After you upload an implementation, you see a list of existing implementations, which includes the mock implementation.

Test the REST Connector API

Now that you've defined your REST Connector API and saved the configuration, you'll want to verify that you’re able to send a request and receive the expected results from the web service. Testing a connection is an optional step but can save you time by identifying and fixing problems now before you finalize the connector API. The Test page lets you test one endpoint at a time.

If you provided a descriptor, you have two testing modes to choose from:

Standard testing

If you provided descriptor metadata, the standard testing mode is displayed in which the request and response bodies are generated from the descriptive metadata and displayed in the Request and Response tabs. All you have to do is select the parameters to test with for GET methods and include any HTTP headers that you want to test with.
Advanced testing

You can refine your testing by selecting Testing in Advanced Mode (the test mode you enter if you provided a remote service URL). Without descriptive metadata, you select the method and resource to test, include any HTTP headers you want to include, and manually create the JSON body.

Test in Advanced Mode

The advanced test page lets you manually set path parameters, add headers, and the request and response payloads.

To manually configure a connector test:

Click the Test navigation link.
If you provided a descriptor, turn Test in Advanced Mode to On.

The advanced test page displays automatically if you provided a remote service url.
Select the HTTP method that you want to test from the drop-down list.
Specify any resource path parameters in the Local URI field as needed for testing purposes. For example:
```
directions/json?origin=los+angeles&destination=seattle
```
The field is automatically prefixed with the local URI that you defined when you entered an API name. Following our example, the full contents of the field would look like this:
```
myMapAPI /directions/json?origin=los+angeles&destination=seattle
```
Notice that if you defined any rules, the Rules Applied field (below the Body field) displays numbers that correspond to the rules that are applicable for the selected operation. The Remote URL field shows the exact string that will be passed to the service for the test.
Add one or more request or response HTTP headers as needed.

These headers are for testing purposes only and won't be added to your REST Connector API configuration.
Click in the HTTP Body field to create your message body (the payload) in the source editor.
For example:
```
{
  "status":"ZERO_RESULTS",
  "routes":[ ]
}
```
Keep the content of the message body relevant to the purpose of the connector, that is, don’t bloat the message by adding extraneous data. Including only pertinent data in the message body facilitates quick transmission of the request or response.
If the service that you're connecting to requires authentication, open the Authentication section and enter your mobile user credentials for each method you test. If you’re using default test credentials, you can skip this step.

With SAML-based security policies, the identity of the user making the call is propagated to the external service. For other security policies such as HTTP Basic Authentication and username token, the credentials used to authenticate with the external service are provided in the policy overrides as CSF keys. Depending on the operation that you’ve defined, you may have to enter specific credentials for each operation or you might be able to use one set of credentials for all the methods to authenticate your connector with the service.
Click Save as current mobile backend default credentials to save the user name and password that you provide as the default.
If you’re in the design phase of creating your connector and you just want to see if your endpoints are valid, click Default API Designer Test Credentials and select a mobile backend that you’re registered with and its version number.
Optionally, you can enter your mobile user credentials (user name and password).
These default test credentials are persistent across all the methods that you test. They remain valid during the current Mobile Hub session.
Click Test Endpoint.

Test Endpoint toggles to Cancel Test when you click it. If you want to stop the test for any reason, click Cancel Test.

Click Reset to clear the fields and modify the test parameters.
Click Done when you’ve finished testing your endpoints.