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.
Note:
Stambia DI is a flexible and agile solution. It can be quickly adapted to your needs.
If you have any question, any feature request or any issue, do not hesitate to contact us.
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
