Virtualizing a REST API without recording or synchronization

Consider the following scenario: You have the description of a REST API that uses path parameters, but no formal definition (WADL, Swagger, or RAML) is available. However, you want to build stubs for the API so that you can test the clients against those stubs when the real service is being implemented. With Rational® Integration Tester you can virtualize the REST API manually, that is, without recording, or when you have no WADL documents, Swagger definitions, or RAML definitions to synchronize. This topic provides an overview of the virtualization process by using the phonebook sample.

1. Open the following URL: https://mydefaultserver:5443/RTCP/examples/. Note that there are five requests under Phone Book.
2. Create web URL schemas for the URL patterns used: /RTCP/examples/phonebook/api/ and /RTCP/examples/phonebook/api/{id}.

   

   For details, see Creating a Web URL schema.
   1. For both the URL patterns, click the green plus icon (Add new URL template), add a path segment of type Literal with the value /RTCP/examples/phonebook/api/.

      

   2. For the second URL, also add a new path segment of type Parameterized with the value id, which will be the name of the parameter.
   3. Change Type to Integer.
   4. Enter meaningful names for the URLs, for example, phonebook and entry respectively, because you will refer to them by these names in the remainder of this procedure.
3. In the Architecture School perspective, create a transport for the host that is running on port 5443, as applicable. For details on how to create an HTTP transport, see Creating HTTP transports.
4. Create operations as recommended in the following table. See Creating an operation.
   For each operation, open the operation editor by double-clicking it and do the following steps:

   1. Go to the Message Exchange Pattern tab.
   2. Select the transport you created in Step 3.
   3. Select the Web URL schema identified in the first column of the following table. Use the names you entered for them in Step 2 for selection. Also select a JSON schema which is needed for the response.
   4. For HTTP Method, use the value identified in the first column of the table.
   5. Open the Stub tab.
      1. Select the transport you created in Step 3.
      2. On the Property Filters tab, select the Filter resource path check box.
      3. In the Resource Path field, enter /RTCP/examples/phonebook/api/. The Resource Path field never contains path parameters because these are identified in the selected Web URL schema.
      4. For the subpaths field, select values from the second column of the table.
      5. Ensure that the Filter HTTP method field is set to the HTTP method identified in the first column of the following table.
   For details on how to change the Message Exchange Pattern of an operation, see Changing the message exchange pattern for an operation. For details on how to use resource paths and sub paths, see Changing the stub page for an operation.

   GET /RTCP/examples/phonebook/api/	The operation does not accept subpaths.
   GET /RTCP/examples/phonebook/api/{id}	The operation (created by using a REST schema) accepts only subpaths.
   POST /RTCP/examples/phonebook/api/	The operation accepts only the exact path as specified.
   PUT /RTCP/examples/phonebook/api/{id}	The operation (created by using a REST schema) accepts only subpaths.
   DELETE /RTCP/examples/phonebook/api/{id}	The operation (created by using a REST schema) accepts only subpaths.

5. Create a multi-operation stub for all of (or a subset of) the operations that you created in the previous step. For details, see Stubs with multiple operations.