When creating a REST Service without a WADL, it is often useful to be able to generate these documents anyway, so that validation is made possible, and code/documentation generation tools can be used. For this SoapUI automatic inference of WADL from the model you create in SoapUI, and also inference of XSD schemas from any incoming responses that can be converted to XML, such as XML, JSON and HTML.
This brief tutorial will walk you through the schema inference functions of SoapUI. We'll start out by creating a new project, naming it "Demo Project". We'll be creating a REST service, without an initial WADL file, so check the "Add REST Service" check mark:
Creating the project and service
As a starting point for the service, we have the following URL:
Check the "Extract Resource/Method" check box, and SoapUI will parse the URL, extracting the parameters.
Three parameters have been extracted, these are "appid", "query" and "output". We are presented with the choice to place these parameters in either the resource, or the method. For this example, let's place the "query" and "output" parameters in the method, leaving the "appid" parameter in the resource. All methods inherit the parameters from their parent resource, and child resources inherit from their parent resources. Where to place a particular parameter depends on how we wish to structure the service.
Once the resource is created, we are presented with creating a method. The parameters we decided to place in the method are now shown here. Let's change the name of the method and then go on.
Inferring an XSD schema
Now we have a request to work with. The request holds all the parameters defined in one of its ancestors. These parameters have been pre-populated using the default values. Clicking on the green arrow icon submits the request, and we can view the response XML.
The response view has a tab along the bottom that now reads "Schema (conflicts)". This is the inferred schema inspector. It has analyzed the XML response, and is telling us that there are conflicts between the current response and the previously inferred schema. This is as it should be, as no prior schema exists. Clicking on the tab opens the inspector, and allows us to resolve these conflicts. Clicking the "Resolve conflicts" button prompts us with the first conflict and a proposed action, to which we can either accept or decline. Since the response we got looks OK, let's click on "Yes to all" to allow the schema inferrer to automatically resolve all conflicts.
If we now click on the "Schemas" tab of the inferred schema inspector, we are shown the inferred schemas for this project. So far we can see one namespace, and the associated XSD schema for it. As this schema is based on only one response we can refine it by making some more requests. While doing so we should try to vary the responses so that they are as different as possible. For instance, we should issue an invalid request so that we can infer the schema for a fault, we should make a request for a query that returns an empty result set (which can be done by setting the query parameter to a random string of characters of sufficient length), etc. While doing this against a working server, we assume the responses will always be valid, so we can check the "Auto-Resolve" check box on the "Conflicts" tab. After a bit of testing, we now see that we have two namespaces listed in the "Schemas" tab. These are "urn:yahoo_srchmi" and "urn:yahoo:api", the latter containing the "Error" element definition.
Using Inferred Schemas
These inferred schemas can be used just like manually created ones. This means that you can use them in assertions to validate your responses. You can export them together with the generated WADL to distribute, or use with other code-generating tools. You can even use them to generate HTML documentation for your service directly out of SoapUI.
Schema for JSON content
Schema inference in SoapUI works for any content that can be converted into XML internally. That means any response that shows up in the XML view can have a schema. Let's try this now.
Change the "output" parameters value to "json". This causes the response given from the service to be formatted in JSON instead of XML. For this demonstration, make sure that the "Auto-Resolve" check box in the inferred schema inspector is checked. Issue the request. Once the response has been returned we can view it both in JSON format, and in XML format converted by SoapUI. This XML representation is different in structure from the one we got when specifying "xml" as the output type. If we view the inferred schema inspector we can now see a new XSD schema. This is an inferred schema for the JSON response converted to XML. With this it is possible to assert the content of JSON responses.