Derivatives of HttpService

Only resource-loader standard service is implemented as an HttpService as it relates to the standard HTTP GET operation. You can also use RestService without losing any capability.

Resource loader (resource-loader)

The following are the specialized interfaces and classes available for resource-loader service:

  • com.hcl.unica.system.integration.service.resourceloader.DefaultWebResourceLoaderService
    The com.example.service.rest.ResourceLoaderService class in asset-integration-starter project is a quick starter implementation for the resource-loader service and extends from the following class:
    com.hcl.unica.system.integration.service.resourceloader
    .DefaultWebResourceLoaderService

    DefaultWebResourceLoaderService class is the default implementation of resource-loader service provided by the Content Integration SDK. If the plugin does not implement its own resource-loader service, Content Integration Framework falls back on this default implementation. Default implementation of resource-loader provided by Content Integration SDK simply follows the given resource URL and retrieves the web resource from target system. It encapsulates the standard HTTP GET operation.

    If the plugin needs to have its own resource-loader implementation which slightly modifies the standard HTTP GET, we recommend extending it from the DefaultWebResourceLoaderService class. It is not necessary to extend resource-loader implementation from the DefaultWebResourceLoaderService if the plugin must use a completely different approach for loading contents, such as reading from file system, database, FTP server etc. In such a case, it must extend from either HttpWebResourceLoaderService for HTTP-based approach or WebResourceLoaderService for functional approach.

  • com.hcl.unica.system.integration.service.resourceloader.HttpWebResourceLoaderService

    The DefaultWebResourceLoaderService class discussed earlier extends from the HttpWebResourceLoaderService abstract class. This class defines the input type and the type of HTTP response received from target URL for resource-loader service as com.hcl.unica.system.model.request.resourceloader.ResourceRequest and byte[] respectively. ResourceRequest class encapsulates the resource URL and system identifier. Similarly, resource-loader works with a byte array when the content from remote HTTP URL is successfully read.

    If the plugin does not extend its resource-loader implementation from the DefaultWebResourceLoaderService class, it must at least extend from com.hcl.unica.system.integration.service.resourceloader.HttpWebResourceLoaderService class to be recognized as a resource-loader service by the Content Integration Framework (Functional counterpart, discussed later, is also a valid choice to extend from for the resource-loader services implemented using the Functional approach).

  • com.hcl.unica.system.integration.service.resourceloader.AbstractWebResourceLoaderService
    The HttpWebResourceLoaderService class discussed in previous point extends from AbstractWebResourceLoaderService abstract class. This class defines the following service gateway interface for the resource-loader service:
    com.hcl.unica.system.integration.service.gateway
    .ResourceLoaderServiceGateway

    To know the role of service gateways in service invocation, see Service invocation. ResourceLoaderServiceGateway interface defines ResourceRequest and HttpResponse<?> as input and output types for the resource-loader service. HttpResponse is an interface, implemented by the WebResource class. It encapsulates the HTTP response headers, body, or payload, and cookies received from the remote URL. Even if the customized resource-loader service does not fetch the content over web, it must return the object of the WebResource (or any other implementation of HttpResponse) populated with the appropriate details. Failing to populate the WebResource appropriately may lead to content loading issues for client applications. The WebResource provides a builder API to create an object with necessary details. The most important thing is to populate the Content-Type header so that client application can deal with the payload accordingly. Similarly, Content-Disposition header must also be populated appropriately containing the filename associated with the content.