REST-based connector considerations¶
Introduction¶
Multiple Integration Studio connectors can be used to connect to RESTful web services, also known as REST APIs. This page provides considerations for choosing which connector to use, selecting from two generic HTTP connectors or numerous application-specific connectors. Custom REST-based connectors can also be created.
High-level considerations and future deprecation¶
Application connectors often include endpoint-specific features that are easier to configure using the specific connector rather than the generic connectors. However, the generic connectors generally allow for more flexibility in configuration. Custom connectors offer additional options that require up-front work to create but make it easy for users to use your branded connector with configurations that may otherwise be unavailable.
Generic connectors¶
Jitterbit provides two generic connectors for connecting with REST APIs:
- HTTP: The HTTP connector is Jitterbit's original HTTP connector whose underlying code has been in use for more than a decade. This connector is proven and trusted but is difficult to extend and maintain. Therefore future development will not be focused on this connector.
- HTTP v2: The HTTP v2 connector is Jitterbit's next version of the HTTP connector. It has been rebuilt using Jitterbit's extensible Connector SDK, which allows new features to become available faster. The HTTP v2 connector has support for additional authentication types, keep-alive connections, and URL parameters in request/response schemas. Future development will focus on this connector.
Jitterbit supports both the HTTP and HTTP v2 connectors.
Jitterbit's long-term intention is to deprecate the HTTP connector, which will be announced in accordance with Jitterbit's End-of-life policy. At present, there is no timeline for deprecation and the HTTP connector remains fully supported. We recommend that you convert existing HTTP connections and activities to HTTP v2 when possible.
Application connectors¶
Numerous application connectors are available and continue to be developed.
In most cases, if an application connector is available for your endpoint, you are encouraged to use it over one of the generic HTTP connectors. Application connectors often include endpoint-specific features that are easier to configure using the specific connector rather than the generic connectors. However, if you have a specific need that is not available in the application endpoint, using a generic connector is a logical alternative.
Considering Jitterbit's intention to eventually deprecate the HTTP connector, we recommend using application connectors or the HTTP v2 connector in new project designs wherever possible.
Custom connectors¶
For extended flexibility, you can create custom connectors using Connector Builder or the Connector SDK:
- Connector Builder
Custom Connector Builder connectors can be designed to use either basic or no authentication. During creation of the connector, you select from the supported HTTP methods of GET, POST, PUT, DELETE, PATCH, or MERGE to create the corresponding activities for users to configure. - Connector SDK
Custom Connector SDK connectors can be designed to use any authentication type, and support for any method can be built into the connector. This type of custom connector offers the most flexibility, as a developer can add enhancements according to your organization's needs.
Capability matrix for Jitterbit connectors¶
Connector Capability | HTTP v2 Connector | HTTP Connector | Application-specific Connector |
---|---|---|---|
Authorization Support | An HTTP v2 connection supports these authorization types: | An HTTP connection supports these authorization types:
| Support varies by connector. |
HTTP Method Support | The HTTP v2 connector supports these methods with these activities of the same name: | The HTTP connector supports these methods with these activities of the same name: | Support varies by connector. |
Operation Pattern Support for Activities Used as Sources | HTTP v2 activities used as a source can be used with these patterns:
| HTTP activities used as a source can be used with these patterns:
| Support varies by connector. Most application-specific connector activities used as a source can be used with these patterns:
|
Operation Pattern Support for Activities Used as Targets | HTTP v2 activities used as a target can be used with these patterns:
| HTTP activities used as a target can be used with these patterns:
| Support varies by connector. Most application-specific connector activities used as a target can be used with these patterns:
|
Schema Support | Custom request and response schemas are optional and can be provided by the user during HTTP v2 activity configuration. If custom schemas are not provided in the activity configuration, default schemas that support a general REST API design will be used. | Custom request and response schemas are optional and can be provided by the user during HTTP activity configuration. | Support varies by connector. Request and response schemas may be generated directly from the endpoint or custom schemas support may be available. |
File-based Jitterbit and JavaScript Functions | Write the data to a temporary file and then use the string reference path to that temporary file activity as the sourceId or targetId function parameter. | Use the string reference path to the activity as the sourceId or targetId function parameter. | Write the data to a temporary file and then use the string reference path to that temporary file activity as the Some connectors may have additional support. |
Number of Retries | Maximum of 5 retries sent at up to a 5-second interval. Supported on private agents only. | Higher maximum (recommended no more than 5 retries) at up to a 5-second interval. Supported on private agents only. | Support varies by connector. |
Transfer Timeout | 30 seconds by default. The | 3,600 seconds by default. The Jitterbit source variables and target variables whose names end with | Support varies by connector. |
Support for Redirects | 50 redirects by default. The | Redirects are not followed by default. The Jitterbit source variables and target variables whose names end with | Support varies by connector. |
Support for Form Data | The Multipart setting of HTTP v2 POST, PUT, and PATCH activity configuration can be used to support RFC 1687 form uploads when using default schemas. Not supported with custom schemas. | The Jitterbit target variables whose names include http.form_data can be used with RFC 1687 form uploads. | Support varies by connector. |
Support for Removing Trailing Whitespace and Line Breaks | Request whitespace and line breaks are left unchanged by default. The | The http.remove_trailing_linebreaks Jitterbit target variable can be used to remove leading and trailing whitespace and line breaks. | Support varies by connector. |
Keep Alive Setting | The Keep Alive setting in an HTTP v2 connection can be used to keep a single TCP connection open for multiple HTTP requests and responses. | Not supported. | Support varies by connector. |
Support for Cookies | Not supported. | Supported only if using a private agent and the jitterbit.http.enable_cookies setting is set to true in the agent configuration file (jitterbit.conf ). | Support varies by connector. |
Support for Custom Certificates | Not supported. | A certificate to authenticate with the HTTP server can be specified using the Certificate field of an HTTP connection. | Support varies by connector. |
Support for Expect: 100-continue | Not supported. | The Expect: 100 continue header is sent when Send Expect 100-continue is selected in an HTTP connection. | Support varies by connector. |
Support for Weak Ciphers | Not supported. | HTTP servers that use weak ciphers (DES/3DES and RC4) can be used when Allow Weak Ciphers is selected in an HTTP connection. | Support varies by connector. |
Support for Jitterbit Plugins | Not supported. | Jitterbit plugins are available to configure during the last step of HTTP activity configuration (see Plugins Added to an Activity). | Not supported. |
Support for Logging on Private Agents | The HTTP v2 connector supports connector verbose logging. | The HTTP connector supports Curl debug logging. | Support varies by connector. |
Note for HTTP GET activities¶
When an HTTP GET activity is used as Target Activity 1 / Source Activity 2 in the Two-target HTTP archive pattern, the activity returns a message indicating success {"success": true}
or failure {"success": false}
instead of the actual response.
File-based Jitterbit and JavaScript functions¶
File-based Jitterbit and JavaScript functions are listed below. HTTP connector activities can be used directly as a function parameter. For use with HTTP v2 and application connectors, write the data to a temporary file and then use that temporary file in the scripting function.
Jitterbit functions
ArchiveFile
Base64EncodeFile
DBLoad
DBWrite
DeleteFile
DeleteFiles
DirList
FileList
FlushAllFiles
FlushFile
ReadFile
SfLookupAllToFile
WriteFile
JavaScript Jitterbit functions