Skip to content

Custom REST Catalog Interface Requirements

Audience: Integration Developers, Application Admins

Content Summary: This guide describes the requirements for a REST Catalog service.

Overview

Immuta provides a basic set of catalog integrations for several of the most widely used data catalogs on the market today. This set is ready to use "out-of-the-box," meaning that with some simple configuration, a basic integration is possible based on Immuta's interpretation of the "standard" model used by each of these catalogs. These provided integrations are great, but what if

  • You are using one of these catalogs, but your usage deviates from the "standard" or "default"?

    • Many of these tools offer customers a tremendous amount of flexibility. This includes customizing fields, models, or any number of enhanced features. Any deviations such as these from Immuta's "standard" interpretation would require Immuta to change the whole provided package. If that were done, the change would be felt by any of Immuta's customers using the integration, and thus changes to these provided integrations are often difficult to make.
  • You are using one of these catalogs, but would like additional metadata to be available perhaps from some other system that Immuta does not have a built-in integration for?

  • You are using a catalog, but not one with a built-in integration?

The Custom REST Catalog interface was developed by Immuta to address all the above and similar circumstances. The diagram below highlights the main feature of Immuta's Custom REST Catalog.

Provided vs. Custom REST Catalog

As the diagram shows, the key difference between the provided catalog integrations and the custom REST catalog interface is that instead of Immuta providing built-in code to directly call the APIs of these various catalogs, Immuta makes a defined set of API calls to a Custom REST service developed by the customer to retrieve this metadata. The Custom REST service receives Immuta's calls, and then is at liberty to do whatever the customer needs to do to collect the relevant information and deliver it back to Immuta. This may take the form of making API calls to various catalogs or other systems - including proprietary solutions.

By providing this specification, Immuta has removed itself from needing to participate in the customization process. Customers can build and maintain their own solutions that provide whatever metadata is required to effectively use Immuta within their organization.

Section Contents