Create a REST Query

You can create a REST query for the GET, PUT, POST, and DELETE methods.

Create the data source that you want to use in the query.
Create an entity to specify the query response. The entity fields that you want to map with the query output parameters must contain the same names as the parameters.
It is recommended that you add the environment variable, no_proxy, to the System Variables. You should also add references to localhost as well as nodes which are targets of REST Queries to the System Variables. Be aware that the case of the environment variables for the a data source target in Operations Hub should match the case of the ones used by the Historian Server; environment variables are case-sensitive.

Note: REST query will run even when system variable has no port number. A bad port leads to an error.

In the module navigation menu, select QUERIES.
The QUERIES workspace appears.
Select Add new query.
The Create Query window appears.
In the Query name box, enter a name, and then select Create. The name must contain at least one uppercase or lowercase letter.
The available options for creating the query appear.

Provide values in the available boxes as specified in the following table.


Box	Description
Description	Enter a description for the query.
Type	Select REST.
Method	Select the method of the API you want to use in the query. Supported methods are GET, PUT, POST, and DELETE.
Entity	Select the entity that will specify the query response fields. Note: When using a Historian data source, the Entity field will auto-populate with the entity associated with the Available API selected.
Data Source	Select the data source that you want to use for the query.
Available API	Select the API that you want to use in the query. This box contains a list of APIs that are available in the data source that you have selected. The list of available APIs will be filtered based on the method selected. Note: Pre-existing APIs are available only for Historian data sources. For more information see: the Historian API help.

Note: The Base URL and Query URL boxes are populated with the base portion (that is, the host name or IP address of the data source server) and the remaining portion of the URL. The values in these boxes together identify the complete URL endpoint. The Base URL box is always disabled. The Query URL box is disabled if you select an API for a Historian data source. If, however, you are using a custom data source, you can enter a value in the Query URL box.

In the Parameters section, please create parameters as needed for the API you are querying. Each parameter will require a default or test value if you wish to run the query with the Execute button.


Type of Parameter	Description	Example
Path parameters	Identify the parameters in the path of the endpoint. These appear before the query string if query parameters are present.	For the endpoint `https://jsonplaceholder.typicode.com/users/1/posts`, the parameter between `users` and `posts`, which is the user ID, is the path parameter. The value for this parameter is 1.
Query parameters	Identify the parameters in the path of the endpoint that appear after the question mark (?).	For the endpoint `https://jsonplaceholder.typicode.com/posts?userId=1`, `userId` is the query parameter. The value for this parameter is 1.
Header parameters	Identify the parameters that you want to include in the request header. Typically, these parameters are related to authorization.
Body parameters	Identify the parameters in the body of the request. Typically these will be required for PUT and POST methods, although they are sometimes required for DELETE as well. Body parameters can be supplied in Operations Hub as a URL encoded format, raw JSON, or raw XML. In case JSON or XML is selected, the first parameter should be used to supply the full JSON body. Subsequent parameters can be used for dynamic substitution into that JSON body. JSON: If selected, the subsequent parameters should be JSON keys found in the body. The corresponding JSON values will be substituted. XML: If selected, the subsequent parameters should be strings found in the body. These strings will be substituted. You can also supply curly braces to delineate the parameters from text within the body. For example, `{{STRING_TO_SUBSTITUTE}}` Additionally, you have the option to preview the substitution for XML.

Be aware that the following Historian REST queries require the multi-select input to be enabled on the EndApp page for output data to be displayed:

Get > Raw Data
Get > Calculated Data
Get > Interpolated Data
Post > Raw Data
Post > Calculated Data
Post > Interpolated Data

In the Query Outputs section, provide values as specified in the following table.


Box	Description
Raw Response	Select this check box if you want to get either the entire JSON response or XML response mapped to a single entity field. You can then access the response by referencing that entity field while designing an application. If you clear this check box, individual components of the response are mapped to individual entity fields.
Entity	Select the entity that will specify the query response fields.
Output fields	Select the entity fields that you want to map to the query response. If the Raw JSON check box is selected, only the first field that you select will be mapped to the query response, regardless of the field name. If the Raw JSON check box is cleared, the JSON response components are mapped to the entity fields with matching names. In the case of nested responses, dot notation is used to map to inner fields.

Note: All REST queries must have a defined response. You can save the query only if you specify at least one output. This is true even for Delete REST API calls which do not normally return a response. In this case, please select any entity and entity field, regardless of name.

In the Execute section, select Run Request.
The query output fields, as well as the query appear in the Results box.
Important: Provide sample values leading to a successful response in order to properly test the REST endpoint. We strongly recommend using values you know will return a representative set of data; otherwise, an error occurs or the response may not return the field data that you need. For example: for Historian data queries, if the set of requested tags is different from the returned set of data (that is, if one or more tags does not have data), the call will fail. The user should modify the inputs to include only the tags for which they are confident there will be data in the response. For PUT/POST/DELETE, this action is not a test but an actual request which can change your data.
If required, select Create Entity from Results. This will create an entity with the appropriate output fields generated from the previous Run Request.
Select Save or Save and Exit.
The query is created.
Note: While Operations Hub handles many response formats, there are some responses which it has difficulty mapping to output fields. In particular, embedded lists may be returned as strings rather than lists of objects.
Important: When you have a large number of users (greater than 100) and each using an end app with multiple REST requests, coupled with a slow REST response, you can get into a situation where the server is waiting for a long time for the previous responses to return, and is therefore unable to process new requests. To avoid this situation, reduce the number of REST calls in your App. Alternatively, you may adjust the Operations Hub timeout setting in the settings.conf file in the following folder: C:\ProgramData\GE\Operations Hub\iqp-config\IQP\app. Use the following command so that the slower REST requests do not hold up the Operations Hub server. You can change the seconds value to increase the timeout setting further:
```
#REST client timeout (seconds) 
rest_timeout=30
```