Double-clicking a REST Request in the navigator opens the REST Request editor window:

Just like the corresponding SOAP Request Editor, this window has the following components:

• A toolbar at the top (two rows) with standard actions and the endpoint dropdown for easily changing the service endpoint
• A Request Editor to the left with corresponding editor views along the left border and editor tabs at the bottom
• A Response Editor to the right with corresponding editor views along the left border and editor tabs at the bottom

The second row of the toolbar adds a dropdown for easily selecting which accept-encoding to send with the request, as this is a common way for a REST Resource to decide which representation it should return. The dropdown is pre-populated with the types specified in the response representations for the corresponding Method:

Tip: Please note that far from all REST Resources use this header, so make sure that your specific Resource supports this before attempting to select which response representation to get with the Accept header.

Let’s have a look at the request and response editor views and tabs.

1. Request Editor Views

The Request editor has the following editor views available along the left border:

• Request (shown above): shows a tabular view of all the parameters defined for the Request, these are the aggregate of the containing Method and its Resource and any parent Resources available (If you want to add new parameters you will have to do this at the method or resource level). Add your desired parameter values in this table (property-expansion is supported also).
  
  If the Method uses an HTTP Verb that sends a request body (POST or PUT), a corresponding editor for the message content is made available under the table of parameters:
  
  
  
  If the Method is linked to a XML Schema definition (in an imported WADL), the recreate button can be used to generate a new message in accordance with the schema. The "Media Type" drop-down provides a number of standard media types for the request body, but you are free to enter any other value instead.
  
  If you want to insert the message body from a file instead then leave the editor empty and add a single attachment with the same content-type as the set media-type for the message; soapUI will insert the contents of the file into the message body instead of attaching it as a MIME attachment (described below).
  
  If you want to simulate the submit of an HTML Form using the " multipart/form-data” content-type you can specify individual parameter values to be read from a file by setting their value to “file:” which will insert the file into the outgoing request.

• RAW: just as for SOAP Requests this shows the Raw bytes sent for the last request. After submitting a request it will contain something like:
  
  
• Outline (soapUI Pro only): Shows a tree-view over the message body (only applicable for POST and PUT requests), for example:
  
  
  
  in the message body will result in the following editor:
  
  
  
  For complex messages this can be easier to work with than the Raw XML view if an XML Schema is not defined (which would allow you to use the Form editor instead).
• Form (soapUI Pro only): Renders a nicer input form for both the requests parameters and its eventual message body schema. For example the imported Yahoo Search method gets rendered as follows:
  
  
  
  As you can see this provides some additional benefits over the simple table-based editor (validation, drop-downs, etc).

Request Message Tabs

A number of tabs are available along the bottom of the Request Parameters View; let’s have a look at them in order to see how they can be used:

• Aut: Allows you to specify HTTP Authentication information:
  
  
  
  Specifying username and password will allow soapUI to authenticate with the service using Basic HTTP Authentication (if challenged by the server). If you want soapUI to send credentials directly without a challenge, then select the “Preemptive Authentication” option in the global HTTP Preferences. In this case you can see the credentials in the Raw message tab after sending:
  
  
  
  Specifying a value in the Domain fields also allows soapUI to authenticate with NTLMv1 servers (NTLMv2 is not directly supported but can be accessed by using a third party tool like...).
• Headers: Allows you to add arbitrary HTTP Headers you might want to include with your request, for example
  
  
  
  results in
  
  
  
  in the Raw request tab.
• Attachments: Contains any files that should be attached to the request as MIME attachments. If you want to associate the content of a file with any of the parameters when simulating a HTML multipart/form-data form then specify that parameters value as “file:”. For example:
  
  
  
  Here you can see the request has two parameters both specifying file. The first just refers to a file in the file system (“hermes.log”), and the second refers to an attachment (“global-groovy.log”).Setting the media-type to multipart/form-data and posting the query string will send the request as if it were a HTML Form with corresponding File input fields.
• Representations: Shows the defined request representations for the underlying REST Method:
  
  

That’s it for the request editor; let’s have a look at the response editor as well.

2. Response Message Views

The response editor contains several views for visualizing different types of responses;

• XML: shows the current response in XML format. soapUI will attempt to convert both HTML and JSON responses to XML so they can be used in property transfers and scripts just like any other response messages in your functional tests. For example, here comes a JSON response rendered as XML:
  
  
  
  
  
• JSON: shows a nicely-formatted rendering of the returned JSON response (if applicable), the above XML was rendered from the following JSON response:
  
  
  
  
  
• HTML: renders the contents of an HTML response (if applicable), for example if we create a REST service for the soapUI website and define the root page (“index.html”) as a resource with a GET method we can see the results:
  
  
  
  You can click in the page just as usual, pages that are shown in a new window will be opened with the current system browser instead.
  
  Please note that the Browser component used by soapUI does not work on all platforms, in which case you will get a “Browser Component Disabled” message instead.
• Raw: shows the raw bytes received for the response. For the above HTML page this contains:
  
  
  
  
  
• Outline (soapUI Pro): A tree-view over the contents of the XML View. Here you can see the XML version of the above JSON response:
  
  
  
  
• Overview (soapUI Pro): an easy to read view of the XML response message, here once again for the JSON response above:
  
  
  
  (URLs are marked in blue and clickable, they will be opened in the system browser)

The corresponding editor tabs for a response are:

• Headers: shows all HTTP Headers received with the response, once again for the JSON response above:
  
  
  
  
• Attachments: contains all MIME attachments returned by the response
• SSL-Info: shows detailed information on the certificate and certificate chain used if the request was sent over an SSL connectio
• Representations: shows the currently defined Response Representations for the containing method:
  
  
• Schema: allows for generation of an XML Schema for the returned response messages, read more on Schema Inference in soapUI at...
• Table: Shows a tabular view of the XML response message based on the currently highlighted node in the XML or Outline editor. For example if we open the JSON response in the XML editor and place the cursor in the first element we get:
  
  
  
  soapUI has generated a table of the XML content related to the selected node, you can now get a much better overview of the contents of the message.

• XML: Useful when you are in the Outline view, this tab displays the XML for the currently selected node:
  
  
  
  As you can see the XML for the selected “e” element is displayed, and its XPath location is displayed just on top of the XML view.