HTTP Request

When this node is reached, an HTTP request will be executed. The HTTP request node supports:

• All common request methods (GET, POST, PUT, DELETE, PATCH, etc.);

• Query parameters (expressions);

• Basic authentication and Client certificate authentication;

• Custom request headers (expressions);

• Custom response headers (mapped to fields);

• If applicable, a request body (text, file or richtext);

• Response body (text, file or richtext).

The type of request, and the HTTP request details are all specified in the node’s properties. Some properties are only needed for certain request types, as is displayed in the example below.

The properties:

Item	Options	Description
Name		Name of the node. This name is generated by WEM and describes the HTTP request that will be performed. The property cannot be edited by hand.
URL	Expression	The URL that is used for the HTTP request (the server to which the request is sent)
Method	GET,POST, PUT, PATCH, DELETE, HEAD, TRACE, OPTIONS	The HTTP request method that is used in this node
Follow Redirect	Yes/No (checkbox)
Authentication	- None - Basic Authentication - Client Certificate	Specifies if authentication is needed for the request. And if so, what type of authentication. When the ‘Basic Authentication’ is specified, a simple username/password authentication is used. In this case the Username and Password properties are displayed. When the ‘Client Certificatie’ authentication is used, the user is asked to specify the client certificate. The certificate must be available in WEM.
Request body encoding	Raw, Form data url encoding, Multi part form data	specify how the data in the request body should be formatted
Request Body	Text Field	A custom request body can be defined
Response Body	Text Field	A custom response body can be defined
Response status code	Number	Give the response a specific status code.

Request Body Encoding

Overview

When the HTTP method is set to POST, a dropdown for selecting the request body encoding appears. This allows users to specify how the data in the request body should be formatted.

Encoding Options

• Raw: Sends the data as-is without any encoding.

• Form Data (URL Encoded): Encodes the data as key-value pairs, suitable for simple form submissions.

• Multipart Form Data: Encodes the data as a multipart message, allowing for file uploads and more complex data structures.

Edit Request Body Form Fields

When the HTTP method is set to POST, users can edit the request body form fields through the "Edit Request Body Form Fields" button. This opens an overlay called "Multipart Content."

Using the Multipart Content Overlay

1. Add Field: Click "Add" to create a new content item. Enter the Name and Expression.

2. Delete Field: Select the content item you want to remove and click "Delete".

3. Save Changes: Click "Save" to apply your changes.

4. Cancel Changes: Click "Cancel" to discard any changes made.

Key Properties

• Name: The name of the content item.

• Expression: The value or expression for the content item.

Edit Query Fields

The "Edit Query Fields" section allows users to customize the parameters sent with their HTTP requests. This is particularly useful for adding dynamic data to your requests.

Key Properties

1. Name: The name of the query parameter. This is the key that will be sent in the URL.

2. Expression: The value or expression associated with the query parameter. This can be a static value or dynamically generated based on application context or user input.

Adding a Query Field

1. Click on Edit query fields: This button opens the query field overlay.

2. Click on +add: Found in the top left of the query field overlay.

3. Enter Field Details: Fill in the Field Name and add query expression.

4. Save Changes: Use the save button to save the changes and close the window.

Editing an Existing Query Field

1. Select the Field: Click on the query field you want to edit.

2. Modify Details: Update the Field Name or expression as needed.

3. Save Changes: Ensure you save your changes to apply the updates.

Deleting a Query Field

1. Select the Field: Click on the query field you want to delete.

2. Click on "X Delete": This will remove the query parameter from the HTTP request node.

3. Save Deletion: Save the deletion to ensure the field is removed.

Best Practices

• Consistent Naming: Use clear and consistent names for your query parameters to avoid confusion.

• Validation: Ensure that the values you enter are valid and correctly formatted.

Edit Request Headers

Overview

The "Edit Request Headers" property allows users to manage the headers sent with their HTTP requests. This is essential for specifying the format and handling of the request.

Key Properties

• Name: The name of the header.

• Expression: The value or expression for the header.

Default Headers

• Accept: */*

• Connection: close

• Content-Type: (empty)

Using the Request Header Overlay

1. Open Overlay: Click the "Edit Request Headers" button to open the request header overlay.

2. Add Header: Click "Add" to create a new header. Enter the Name and Expression.

3. Delete Header: Select the header you want to remove and click "Delete".

4. Save Changes: Click "Save" to apply your changes.

5. Cancel Changes: Click "Cancel" to discard any changes made.

Edit Response Headers

Overview

The "Response Headers" section allows users to manage the headers received in the HTTP response. This is useful for handling and processing the response data.

Key Properties

• Name: The name of the response header.

• Data Field: The datafield the response header is mapped to.

Using the Response Header Overlay

1. Open Overlay: Click the "Response Headers" button to open the response header overlay.

2. Add Header: New rows are added when the Name and Data Field are filled in.

3. Delete Header: Select the header you want to remove and click the "Delete" button.

4. Close Overlay: Click the "Close" button to exit the overlay.

Exits

The Web request node can have several exits. There are two pre-defined exits:

• Default exit

• Error

  This is the standard error exit for every WEM Node to catch technical code issues within the node itself to prevent showing technical error-details to end users. In this case it should not be used to handle Fault Messages from the Response (which are correct results within the HTTP Request Process - not errors - and have specific HTTP Response Codes which can be handled specifically)

Besides these pre-defined exits, it is possible to define an exit for every possible status code the HTTP Request returns. This includes any "error messages" or "fault messages" that the remote endpoint can provide.

List of HTTP Status Codes:

https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

HTTP Status Code Exits

The HTTP Request Node allows you to add exits for specific HTTP Status Codes (or response codes) that the resulting Response can provide. A link to a list of possible HTTP status codes and types/grouping is provided above and here: (wiki).

You should check with the provider of the remote endpoint to understand which Response Codes you may expect and could handle specifically.

When you define the Exit by HTTP Code, you currently have to define the specific code (there is no option for "wildcards" like 4xx and 5xx - but this may be provided in future). Then, following the specific HTTP Code Exit, you can handle it accordingly, and the Response Body can contain details of the specific situation so you may want to use that Response Body information as well when displaying feedback to user.

HTTP Status Code Exit or Error Exit?

Basically, you will not use the Error Exit to handle errors that occur on the Remote side - the Error Exit should only be used for situations where the Response is not received (there is no HTTP Status Code) - typically this is for when the Request itself is malformed and causes issues in the WEM Runtime. You should leave the Error Exit unlinked to show the technical information from the WEM Runtime that may indicate a bug or another issue that needs to be fixed. To make things confusing: that error may be displayed as a Server 500 (HTTP Status code 500) error, but this may be the status code from the WEM Runtime, and not from the remote endpoint...

HTTP Status Codes in the 4xx range are considered "client errors" and the 5xx range are considered "server errors" - in any case - if this status code is received in the Response object and there is a corresponding exit, this exit is followed and the Response Body will contain the detailed results from the remote endpoint. As this is mapped to a field in your model, you can just display that information or work some logic on its contents.

HTTP Status Codes 4xx and 5xx as received from the remote endpoint are valid Response Status Codes and are NOT considered Errors that will follow the Error Exit.