REST-based connector considerations in Jitterbit Integration Studio

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: API Key AWS Signature Basic Authorization Bearer Token Digest Authorization No Authorization OAuth 2.0	An HTTP connection supports these authorization types: Basic Authorization Digest Authorization	Support varies by connector.
HTTP Method Support	The HTTP v2 connector supports these methods with these activities of the same name: GET POST PUT DELETE PATCH HEAD OPTIONS	The HTTP connector supports these methods with these activities of the same name: GET POST PUT DELETE Custom (any user-specified verb)	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: Transformation Pattern Two-target Archive Pattern (as the first source only) Two-target HTTP Archive Pattern (as the first source only) Two-transformation Pattern (as the first or second source)	HTTP activities used as a source can be used with these patterns: Archive Pattern Transformation Pattern Two-target Archive Pattern (as the first source only) Two-target HTTP Archive Pattern (as the first or second source) (See Note for HTTP GET Activities below this table.) Two-transformation Pattern (as the first source only) Salesforce Bulk Target Pattern	Support varies by connector. Most application-specific connector activities used as a source can be used with these patterns: Transformation Pattern Two-target Archive Pattern (as the first source only) Two-target HTTP Archive Pattern (as the first source only) Two-transformation Pattern (as the first or second source)
Operation Pattern Support for Activities Used as Targets	HTTP v2 activities used as a target can be used with these patterns: Transformation Pattern Two-transformation Pattern (as the first or second target)	HTTP activities used as a target can be used with these patterns: Archive Pattern Script Pattern Transformation Pattern Two-target Archive Pattern (as the second target only) Two-target HTTP Archive Pattern (as the first or second target) (See Note for HTTP GET Activities below this table.) Two-transformation Pattern (as the second target only) Salesforce Bulk Source Pattern	Support varies by connector. Most application-specific connector activities used as a target can be used with these patterns: Transformation Pattern Two-transformation Pattern (as the first or second target)
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 `sourceId` or `targetId` function parameter. 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 `connection-timeout` key in the Additional Settings area of HTTP v2 activity configuration can be used to change the transfer timeout.	3,600 seconds by default. The Jitterbit source variables and target variables whose names end with `http.transfer.timeout` can be used to change the transfer timeout.	Support varies by connector.
Support for Redirects	50 redirects by default. The `max-redirect` key in the Additional Settings area of HTTP v2 activity configuration can be used to change the number of redirects to follow.	Redirects are not followed by default. The Jitterbit source variables and target variables whose names end with `http.max_redirs` can be used to allow redirects to be followed.	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 `trailing-linebreaks` key in the Additional Settings area of HTTP v2 activity configuration can be set to true to remove leading and trailing whitespace and line breaks.	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

JavaScript Jitterbit functions