Following methods can be used:
-
get
-
post
-
put
-
delete
-
head
-
options
-
trace
-
patch
All methods are transcript for an actual call. For example, pfx-rest:get will eventually call GET https://test.me/...
Properties
|
Option |
Type |
Since Version |
Default |
Description |
|---|---|---|---|---|
|
|
string |
|
|
URI to fetch data from. If the parameter If the parameter If there are parameters needed in URI, each parameter should be placed as a placeholder |
|
|
integer |
|
20000 |
Connection timeout in milliseconds. Used both for authentication and fetch. |
|
|
integer |
|
0 |
Defines maximum size of a response in MB. After reaching the limit, an exception will be thrown. If the default value (0) is set, the response size is not checked. |
|
|
string |
|
application/json |
Content type of the fetch request. The value has to follow the HTTP standard. |
|
|
string |
|
200-299 |
Status codes which are considered a success response. The values are inclusive. Multiple ranges can be defined, separated by a comma, e.g. 200-204,209,301-304. Each range must be a single number or from-to with the dash included. |
|
|
string |
|
|
Proxy address to use. |
|
|
integer |
|
|
Proxy port to use. |
|
|
string |
|
|
Name of an existing connection which will be used to access the resource. |
|
|
Boolean |
|
true |
Indicates that encoded data (gzip, deflate, ...) should be automatically decoded. |
|
|
Boolean |
|
false |
Determines whether to fail if a connection is missing or whether to use the default connection. |
|
|
Boolean |
|
false |
If set to true, the content is streamed directly to a file. Otherwise the content is stored to the memory. File location can be set using the |
|
|
string |
|
file |
If a multipart file is uploaded, specifies a key of the file. |
|
|
Boolean |
|
true |
If a multipart file is uploaded, determines whether to use boundary in the request body and content type. |
|
|
string |
4.7.0 |
|
Defines input source for data in exchange. It can be stored in the header, property or body. |
|
|
string |
4.7.0 |
|
Defines input source name for the source type header and property. Put here the name of the exchange header or exchange property. |
|
|
string |
4.7.0 |
|
Defines output target for data in exchange. It can be stored in the header, property or body. |
|
|
string |
4.7.0 |
|
Defines output target name for the target type header and property. Put here the name of the exchange header or exchange property. |
|
|
string |
4.9.0 |
|
If |
|
|
long |
6.2.0 |
20000 |
Response timeout in milliseconds, defining the maximum time for waiting for a response |
|
|
long |
6.2.0 |
20000 |
Connection timeout in milliseconds, defining the maximum time for connecting to a target |
|
|
boolean |
6.2.0 |
true |
Reuse connection for subsequent requests to the same target |
|
|
boolean |
6.2.0 |
false |
Use a minimal keep-alive strategy to determine keep-alive duration. Setting to true would stop reusing connections. |
|
|
boolean |
6.2.0 |
true |
Evict expired connections automatically from the connection pool |
|
|
boolean |
6.2.0 |
true |
Evict idle connections automatically after they have been idle for a specified time |
|
|
long |
6.2.0 |
30000 |
Maximum idle time in milliseconds before an idle connection is evicted |
|
|
integer |
6.2.0 |
200 |
Maximum number of simultaneous connections allowed in the connection pool |
|
|
integer |
6.2.0 |
100 |
Maximum number of simultaneous connections allowed per route in the connection pool |
|
|
boolean |
6.2.0 |
true |
Enable or disable the SO_KEEPALIVE socket option |
|
|
long |
6.2.0 |
3_600_000 |
Socket timeout in milliseconds, defining the maximum time for waiting for data |
Unknown Properties
Unknown properties are handled as query parameters. For details see the section below.
An exception is when using the method pfx-rest:system – in this case, unknown properties are handled as properties.
Input Source / Output Target
A standard way to put data to a component or retrieve them from a component is using body. However, in certain cases it is not the best option. Hence the inputSource, inputSourceName, outputTarget and outputTargetName properties were created to tackle the problem.
An example how to define a component that fetches data from the header header1:
<to uri="pfx-rest:post?uri=http://localhost:8080/api/ad/data&inputSource=header&inputSourcenName=header1"/>
Example how to populate data from the body:
<setBody>
<constant>body123</constant>
</setBody>
<to uri="pfx-rest:post?uri=http://localhost:8080/api/ad/data"/>
Body is default option. You can also set inputSource=body, the effect would be the same.
Example how to send results to the property prop1:
<to uri="pfx-rest:post?uri=http://localhost:8080/api/ad/data&outputTarget=property&outputTargetName=prop1"/>
The toD Problem
The toD option might seem more dynamic:
<setHeader name="MyCustomMap">
<constant>{"somedata":"exactly as endpoint expects"}</constant>
</setHeader>
<toD uri="pfx-rest:post?uri=http://localhost:8080/api/ad/data&payload=\${headers.MyCustomMap}"/>
However, this option has a caveat described here. In short, using toD interpolates the parameters, so the result component is:
<toD uri="pfx-rest:post?uri=http://localhost:8080/api/ad/data&payload={"somedata":"exactly as endpoint expects"}"/>
When you change the data in the header MyCustomMap to data2, this component would be created:
<toD uri="pfx-rest:post?uri=http://localhost:8080/api/ad/data&payload=data2"/>
So if the parameter has variable content (let’s say n), there would be n components and endpoints created, which would negatively affect performance.
In this case, if you use static parameters with <to....inputSource=header&inputSourceName=head1, only one component and one endpoint would be created for all possible values, offering top performance.
Handling ZIP Response
If an endpoint returns a ZIP response (content-type=application/zip) and the disableStreamCache option is set to false, then the response will be stored into memory as a Base64 encoded string. This allows you to work with the ZIP file in a route.
Examples
Call with payload from header
<route>
<from uri="direct:start"/>
<setHeader name="MyCustomMap">
<constant>{"somedata":"exactly as endpoint expects"}</constant>
</setHeader>
<to uri="pfx-rest:post?uri=http://localhost:8080/api/ad/data&inputSource=header&inputSourceName=MyCustomMap"/>
<log message="Loading done!"/>
<to uri="mock:end"/>
</route>
Request body: {"somedata":"exactly as endpoint expects"}
Call with result stored in header
<route>
<from uri="direct:start"/>
<toD uri="pfx-rest:post?uri=http://localhost:8080/api/ad/data&outputTarget=header&outputTargetName=myHeader"/>
<log message="Loading done!"/>
<to uri="mock:end"/>
</route>
Result data will be stored in the header myHeader.
Call with result stored to property
<route>
<from uri="direct:start"/>
<toD uri="pfx-rest:post?uri=http://localhost:8080/api/ad/data&outputTarget=property&outputTargetName=myProp"/>
<log message="Loading done!"/>
<to uri="mock:end"/>
</route>
Result data will be stored to the property named myProp.