HTTP REST Component

This article describes the principal changes of HTTP REST Component.

If you need further information, please consult the full changelog.

Component download section can be found at this page.

 

 

 

Component.HttpRest.2.2.1

Complete changelog

The complete changelog with the list of improvements and fixed issues can be found at the following location.

 

Component.HttpRest.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 as below:

For instance, when mapping the rawContent node of the response to the target it retrieves all the content at once in the target field.

  

The previous mapping retrieves the whole response which is, in this case, JSON data like following which is loaded inside the target field:

{
    "response": {
        "data": {
            "customer": {
                "cus_id": "0",
                "tit_code": "M",
                "cus_first_name": "John",
                "cus_last_name": "Doe",
                "cus_company": "acme"
            }
        }
    }
}

Have a look at this article for further information about this feature.

 

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.

 

Complete changelog

The complete changelog with the list of improvements and fixed issues can be found at the following location.

 

Component.HttpRest.2.1.1

Minor improvements and fixed issues

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

 

Component.HttpRest.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.

Metadata looks like this:

Currently, you can reference it only on HTTP Metadata. We are working on this topic. Soon you can reference it on other metadata.

 

Support Proxy Metadata

HTTP Rest Component now supports Proxy Security.

You must first define the proxy information in a dedicated Metadata. (Refer to this article for more information)

Then you reference it on the HTTP Metadata :

 

NTLM Authentication

HTTP REST Metadata has been updated to support NTLM security.

NTLM security is defined on a new HTTP security node:

Asking to create a new NTLM security node allows to define the Name, UserName, Password and Domain.

Using substitution variables syntax inside the Reverse URL

HTTP REST wizard has been updated to support substitution variable syntax inside the http rest wizard on the Reverse URL such as %{env:variable_name}%

 

HTTP REST Wizard - security Definition

When security metadata and proxy metadata are defined then the security and the proxy will be successively proposed in "HTTP Security" and in "HTTP Proxy" of the Security Definition wizard:

 

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.

 

Complete changelog

The complete changelog with the list of improvements and fixed issues can be found at the following location. 

 

Component.HttpRest.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.

 

 

Example with the written value:

 

Important note:

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

(for example if only the root element of the http datastore is 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.

 

 Example with the attribut: 

 

Note: 

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

 

Complete changelog

The complete changelog with the list of improvements and fixed issues can be found on the full changelog.

 

 

 

Component.HttpRest.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.

 

Definition in Metadata:

 

 

Usage in Mapping:

 

 

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.

 

Example:

 

Connection and Read Timeouts

Prerequisites:

• Stambia DI Runtime S20.3.0 or higher

 

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.

 

Example:

 

 

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

 

Refer to the documentation of the attribute for further information about each value.

 

The attribute in OAuth2 Metadata node:

 

 

The new attribute has also been added in the OAuth2 wizard:

 

 

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.

The following behavior applies:

Legacy attributes values	Default value generated for Send Client Credentials
Send Client Id = true and Send Client Secret = true	Send Client Id and Client Secret as parameters
Send Client Id = true and Send Client Secret = false	Send Client Id as parameter
Send Client Id = false Send Client Secret = false	Empty

 

Minor improvements and fixed issues

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

 

Complete changelog

The complete changelog with the list of improvements and fixed issues can be found at the following location.

 

Component.HttpRest.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.

 

Component.HttpRest.2.0.1

Prerequisites:

• Stambia DI Designer S20.2.0 or higher

 

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.

Note that 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.

 

Launching the HTTP REST API wizard

 

Defining the Open API 3 definition through an HTTP URL or local file (after the security step)

 

Finally, choosing the nodes to reverse

 

You have no rights to post comments