HTTP REST Component Release Notes

This page lists the main features added to the HTTP REST component.

Feature Highlights

Version 2.2.1

This version contains minor improvements and fixed issues, which can be found in the complete change log.

Version 2.2.0

Mapping whole response into one target field

A new extra field is available when using HTTP REST Metadata, under a response node, to be able to retrieve the whole content at once, instead of granular data.

This extra field is named "rawContent" and it can be used as source to retrieve all the response data at once.

You can add it dynamically in Mapping through extra fields.

Handling transparent stage in Integration RDBMS to HTTP rest

Transparent stage allows to define a staging area on a datastore, when the source does not support transformations.

Integration Rdbms to HTTP template has been updated to support using a transparent stage.

Version 2.1.1

Minor improvements and fixed issues

This version contains some minor improvements and fixed issues, which can be found in the complete change log.

Version 2.1.0

Proxy Metadata

HTTP REST Metadata supports Proxy authentication.

This security information is set in a new dedicated Metadata called "Proxy Security" in which you can set the information from the Proxy.

Then, in your HTTP REST Metadata, you will need to define the security node to use for authentication.

This allows the various security information to be centralized into a single dedicated metadata.

NTLM Authentication

HTTP REST Metadata has been updated to support NTLM security.

NTLM security is defined inside an HTTP Security Metadata, and then linked inside the HTTP REST Metadata.

HTTP REST Wizard - security Definition

Main HTTP REST wizard has been updated to propose choosing the Proxy and Security to be used.

The list proposes the existing proxy and security nodes in the current workspace, respectively defined in Proxy Security and HTTP Security Metadata.

Support of EMF Compare

Several improvements have been made to support EMF Compare.

Minor improvements and fixed issues

This version also contains some other minor improvements and fixed issues, which can be found in the complete changelog.

Version 2.0.4

Templates Improvements

Write XML Key Values on INTEGRATION Rdbms to HTTP Template

Addition of the "Write XML Key Values" parameter on the INTEGRATION RDBMS to HTTP Template. If true, mapped XML element nodes that are used as a key will be written to the request even if they don’t have a datatype.

  • when true and no datatype is set on the key node, the value is written.

  • when true and a datatype is set on the key node, the value is written.

  • when false and no datatype is set on the key node, the value is discarded.

  • when false and a datatype is set on the key node, the value is written.

Setting this to false will prevent runtime from sending requests when only key nodes are mapped.

Nil Behaviour on INTEGRATION RDBMS to HTTP Template

Addition of the "Nil Behaviour" parameter on the INTEGRATION RDBMS to HTTP Template. This parameter defines what to do when a null value is loaded into a target xml element or JSON value.

The possible values are:

  • ForceToTrue: The element is created with the xsi:nil="true" attribute.

  • ForceToFalse: The element or JSON value is not created.

  • TrueIfNotDefined: When the 'isNullable' property is not defined in Metadata, the element is created with the xsi:nil="true" attribute.

  • FalseIfNotDefined: When the 'isNullable' property is not defined in Metadata, the element is not created.

All options are supported for XML elements only. The property "nillable" does not currently exist on Json Values.

Certificates and hostname verifications

New attributes allowing to indicate that if certificates and hostname verifications should be performed. These attributes are available in HTTP REST and also in HTTP security OAuth2 Metadata.

On the HTTP REST Metadata, the parameter allows to define if the verification should be performed, for the certificates verifications of the operation itself

On HTTP REST Metadata, the parameter allows to define if the verification should be performed on the exchange performed to get OAuth2 token.

Default values of these parameters are "true" and when setting it to false the certificates and hostname verifications should not performed

Version 2.0.3

Support Multipart Request contents

HTTP REST Component now supports sending multi-part contents as input request.

You can define Multipart request in your Metadata through the new dedicated nodes.

Then, you can use them in Mapping as usual.

If you want to send multiple times the same part in a request, you can simply use the "part" node as repetition key. A part will be created for each value of the repetition key.
You can customize the Part Name and also the Part Filename dynamically through extra fields In Mapping

Response Cookies

HTTP REST Component now allows to design in Metadata the response cookies you want to retrieve.

A new cookie node can be created, with dedicated attributes allowing to identify the cookie to retrieve, such as the cookie name and a regexp.

This node can be created in responses, under the headers node.

Connection and Read Timeouts

This new version allows to define Connection and Read Timeouts at different levels.

You can define them globally on the HTTP REST Metadata, or for each operation, and override them also in Mapping through new parameters on Templates.

This offers agility to define timeouts accordingly to your requirements.

Definition in Metadata

In Metadata, you will find those new attributes under the "Advanced" tab.

The timeouts can be specified globally on the root node, applying to all the operations defined in the Metadata.

They can also be specified directly on an operation node, if you want to define different timeouts on the various operations.

Note that it overrides the default timeouts defined on the root node, if any.

Definition in Template

You can also define the timeouts directly in Mapping, through the corresponding two Template parameters.

Timeouts defined in Templates take precedence over the timeouts defined in Metadata.

If no timeout is defined on the Template, it will use the value from Metadata.

OAuth2 improvements

New parameter to specify how credentiels are sent

Some OAuth2 authentication servers require that the credentials are sent alongside the token generation.

When this is the case, those credentials were legacily sent as parameters by Stambia

However, some servers require those credentials to be sent differently.

A new attribute named "Send Client Credentials" has therefore been added in Metadata to define how client id and client secret should be sent, with the support of a new mode to send them in Basic Auth header.

This attribute is available for the following "Flow Type", which may require it depending on the OAuth2 server implementation:

  • Resources Owner Password Credentials Grant

  • Client Credentials Grant

This new attribute proposes the list of the following values:

  • Send Client Id as parameter

  • Send Client Id and Client Secret as parameters

  • Send Client Id and Client Secret as Basic Auth header

Backward compatibility

Legacy "Send Client Id" and "Send Client Secret" have been moved to a deprecated tab:

When working with a Metadata using the legacy attributes, the default value for "Send Client Credentials" attribute is automatically adapted with the according value.

Minor improvements and fixed issues

This version also contains some other minor improvements and fixed issues, which can be found in the complete changelog.

Version 2.0.2

Previous version was including too much dependencies libraries, which was leading to having a larger archive file for the HTTP REST Component and plugin contained inside.

This has been fixed, the HTTP REST Component size is now back to normal.

Note that except the larger file size, this had no other consequences.

Version 2.0.1

New wizard to define security

A new wizard has been added in HTTP REST Metadata to define the security node to be used.

When creating a new HTTP REST Metadata, a wizard will now open to guide the user to choose the security node to be used if any, and then to continue to the reverse step.

The security page allows to choose an existing security node from all the HTTP Security Metadata of the workspace, which must therefore already exist.

New wizard to reverse an Open API 3 definition

The HTTP REST Metadata now also supports reversing an Open API 3 definition.

The wizard which opens at Metadata creation, and which can be reopened from the context menu on the root node, allows to reverse an Open API3 definition from an HTTP URL or from a local file.

After having defined the url, the wizard will reverse the definition and allows to choose the nodes to save.

Change Log

Version 5.3.11 (HTTP Rest Component)

Bug Fix

  • DI-7089: An error is thrown if the Part Name field contains square brackets, that is, [ and ] characters.

Version 5.3.10 (HTTP Rest Component)

Bug Fix

  • DI-6701: Passwords containing special characters are not encoded correctly when generating OAuth2 tokens. This leads to failed authentication.

Version 5.3.9 (HTTP Rest Component)

New Features

  • DI-6382: The Outgoing Server (SMPTP) and Incoming Account nodes in the email metadata now support Microsoft Outlook’s modern authentication system based on a token mechanism. See Getting Started with Email Server

Version 2.0.1 (HTTP Rest Component)

New Features

  • DI-602: HTTP REST Component - ability to reverse Open API 3 definitions

  • DI-1783: HTTP REST Component - new dedicated wizard to define security and reverse definition

  • DI-1974: HTTP REST Component - Allows to indicate if a parameter supports being sent with an empty value. (Note that an empty value is different than a null / not specified value, which is considered as if the parameter should not be sent at all)

Version 2.0.2 (HTTP Rest Component)

Bug Fixes

  • DI-2661: HTTP REST Component includes too much libraries dependencies, which makes its plugin size larger than expected

Version 2.0.3 (HTTP Rest Component)

New Features

  • DI-1739: Support Multipart contents in Request Body

  • DI-2669: Ability to define and read response cookies

  • DI-2674: Support defining namespaces on the root node and to use them on XML contents

  • DI-1139: Web Services invocation - addition of new attributes in Metadata and Templates to declare a Connection Timeout and a Read Timeout

  • DI-1828: Web Service authentication with OAuth2 - a new parameter named "Send Client Credentials" has been added to define how client id and client secret should be sent, with the support of a new mode to send them in Basic Auth header

Bug Fixes

  • DI-2970: Default value proposed for the "Content-Type Header" attribute when using BINARY or XML Media Type was wrong

  • DI-2972: HTTP Security - in Metadata, the different security nodes should be ordered by type

  • DI-3057: Responses items containing empty values, such as headers with empty values, were ignored

  • DI-2683: When having an XML Request content, root node name and attribute names defined in Metadata are ignored, the name sent is unexpectedly generated as "e" at execution instead of the real name

  • DI-2698: HTTP REST Metadata - the "new" context menu on a "Content" should propose an XML "element" node instead of an XML "root" node

Version 2.0.4 (HTTP Rest Component)

New Features

  • DI-3387: HTTP REST and HTTP Security OAuth2 Metadata - Two new metadata attributes have been added in HTTP REST technology and in HTTP Security Metadata, which allow to indicate if certificate and hostname verifications should be performed.

  • DI-3429: Addition of the "Nil_Behaviour" parameter to INTEGRATION Rdbms To Http template

  • DI-3531: Ability to use HTTP Rest Metadata in Mappings without input parameters

  • DI-1252: OAuth2 - Ability to externalize whole properties through a new "Json Properties" attribute containing a JSON representation of all the OAuth2 attributes and which is automatically generated

Bug Fixes

  • DI-2924: Salesforce metadata - Fixing failed execution of a mapping that uses Salesforce Metadata with the OAuth2 Http security node

  • DI-2975: Template - INTEGRATION RDBMS to HTTP - Added new parameter "Write XML Key values" to write the value even if no data type defined on the key node

  • DI-2976: HTTP REST - Invocation was not performed because some output fields are sometimes automatically mapped with mapping when some names match with the source

  • DI-3338: Reverse REST Wizard - Invocation was failing when using an OAuth2 security node in which the Http Method is not set

Version 2.1.0 (HTTP Rest Component)

New Features

  • DI-2422: HTTP REST wizard - Ability to use string substitution variables inside the HTTP Rest wizard on the Reverse URL (such as %{env:variable_name}%)

  • DI-2667: HTTP REST Metadata - support defining proxy settings, which will be taken into account inside reverse wizards and operation executions

  • DI-2822: Proxy Metadata - Availabilty of a new Metadata to define Proxy settings

  • DI-3510: EMF compare utility - Component has been updated to support EMF Compare comparison utility

  • DI-1716: NTLM Authentication - adding a dedicated wizard on NTML security node, and support NTLM security node in HTTP Security Metadata

Version 2.1.1 (HTTP Rest Component)

Bug Fixes

  • DI-3339: HTTP REST Metadata - when mapping a response JSON Property field to a stage, an error was thrown at execution during the load of data into the stage because the generated datatype was unexpectedly empty

  • DI-3553: HTTP REST Metadata - When mapping a response form value to a stage, an error was thrown at execution during the load of data into the stage because the generated datatype was unexpectedly empty

  • DI-3589: HTTP REST Metadata - The list on "type" attribute was empty on XML elements and XML attributes

  • DI-3939: OAuth2 Security - The "java.io.IOException: Pipe closed" exception could occur when executing a Mapping using the OAuth2 security

Version 2.2.0 (HTTP Rest Component)

New Features

  • DI-1750: HTTP REST Metadata - ability to retrieve the whole response and map into one target field through a new extra field which is available in Mapping on the response node

  • DI-2962: Template - Integration Rdbms to HTTP - support using transparent stages

  • DI-3982: OAuth2 Security - ability to send additional custom HTTP Headers during token generation through a new attribute in Metadata

Version 2.2.1 (HTTP Rest Component)

Bug Fixes

  • DI-4366: When authenticating through OAuth2 with some of the flows, the token was unexpectedly regenerated even if the previous one was still valid

Version 3.0.0 (Component Pack)

New Features

  • DI-128: JSON Metadata: Reverse-engineering JSON schemas

  • DI-2477: New metadata wizards automatically select all the listed elements for selective reverse-engineering.

  • DI-2480: HTTP REST: Reverse-engineering XML structures from XML schemas

  • DI-2973: HTTP REST metadata wizard supports reverse-engineering the response Set-Cookies headers.

  • DI-3701: Allow Components to contribute to Designer monitored statistics

  • DI-4153: JSON writing - ability to choose how to write empty objects and arrays

  • DI-4335: HTTP REST: Configure retries, functional response codes and error messages capture to handle errors occurring on API calls.

  • DI-4508: Update Components and Designer to take into account dedicated license permissions

  • DI-4727: Rebranding: Templates and sample projects

  • DI-4800: HTTP Security and HTTP Proxy are now included as base components

  • DI-4962: Improved component dependencies and requirements management

Bug Fixes

  • DI-4382: HTTPS operations do not work when a proxy is defined

Version 3.0.1 (Component Pack)

Bug Fixes

  • DI-5216: Authorization requests were not sent through the defined proxy

Version 5.3.5 (Component Pack)

Bug Fixes

  • DI-5736 : Error "java.lang.NoClassDefFoundError: io/swagger/v3/core/util/Json" when trying to reverse-engineering some Open API definitions.