You can now build and use a unique HTTP connector to fit your exact needs. This connector will remain private for your use only. To build the connector:
-
Create the HTTP connector using Postman and the configured schemas.
This article goes over some of the concepts around building an HTTP connector.
An API is an application program interface exposed so users can interact with data in software. APIs enable the integration between different software products, allowing them to communicate with each other without needing to know the internal workings of each other's software. A connector can have multiple APIs associated with it. For example, Shopify has Partner APIs and Payment APIs. Both are mutually exclusive APIs designed for different purposes. Each API has its own resources and endpoints.
A connector is a preconfigured form that can connect to a third-party application. The Celigo platform has hundreds of preconfigured application, database, or universal connectors. This Postman collection allows you to create your own HTTP-based connector. A connector creates a link to a software application’s API. Then you can use any available resources and endpoints to gather, modify, or delete data.
A resource typically refers to specific data or information accessible through an API or other integration mechanisms. Resources are the fundamental building blocks you interact with when integrating different systems or applications.
Resources are typically identified using resource identifiers within an API. These are used in API requests to specify which resource you want to interact with. For example, a URL like https://api.example.com/customers/ represents the customers resource that can have multiple endpoints and methods.
Resources are usually represented in a specific data format, such as JSON or XML, which defines their structure and content when retrieved or sent through an API request.
An endpoint refers to a specific URL or URI (Uniform Resource Identifier) representing an application's unique location or resource. Endpoints are a fundamental concept in API design and usage, and they play a crucial role in defining how data and functionality can be accessed and manipulated.
Endpoints are typically represented as URLs or URIs. You can use these web addresses to send HTTP requests to interact with the API. For example, an endpoint URL in an application might look like: https://api.example.com/customers or https://api.example.com/products/123.
Endpoints are not only about where you send requests but also about how you interact with the resources. Different HTTP methods (GET, POST, PUT, DELETE, etc.) are used with endpoints to perform actions like retrieving data, creating new resources, updating existing resources, or deleting resources.
In practice, when working with an API, you specify the endpoint URL and use the appropriate HTTP method to interact with the desired resource. For example:
-
To retrieve a list of users, you might send a
GETrequest to the/usersendpoint. -
To create a new user, you might send a
POSTrequest to the/usersendpoint. -
To update an existing user's information, you might send a
PUTrequest to the/users/<id>endpoint, whereidrepresents the specific user's identifier.
A framework is like a bridge that fills the gap between our universal HTTP connector and external HTTP APIs, giving you a streamlined experience for creating connections, imports, and exports in the Celigo platform.
Before building a connector, it is important to understand how to create metadata and preconfigured fields.
Your metadata refers to data that provides information about other data. In this case, connector metadata consists of preconfigured fields and requirements that remain the same regardless of who created the connection or when it was created. For example, the application’s Base URI (if fixed) or the authentication type (if only one is available) can be set as metadata. An example preconfigured Base URI is https://api.example.com/.
HTTP fields where the user's input varies—either partially or fully—are the fields where users must provide input. Such fields are referred to as fieldsUserMustSet. An example field a user must set is a username or password field.
Custom settings are used to create fields a user can input into. You can typically use custom settings in the following ways:
-
When the corresponding HTTP field has a partial value fixed (like the Base URI or Authentication URLs for OAuth).
-
When the corresponding HTTP field cannot be presented as is, for example, the value for the License ID needs to be passed as an HTTP header. Asking a user to provide the License ID in the header's key-value format would not be pleasant. In this case, we can create a custom setting and assign its value to the user.
For example, in Shopify, your Base URI is https://www.<storename>.myshopify.com. In this case, the store name is the variable the user would have to input.
There are some situations where you wouldn’t want to use custom settings. Typically, authentication-related fields would not be ideal for custom fields. If the underlying application follows a standard authentication mechanism the Celigo platform already supports, you should reuse the available field. For example, the token authentication type is already supported and can be used as a fieldsUserMustSet field.
This is an alternative to custom settings and should be used only if you want to save the user’s input in an encrypted manner. It should be used only in special cases where the authentication type is custom. In the future, you should change this to a different custom setting.
Learn more about a simple vs HTTP form view. Application-specific (simple) forms are based on the universal HTTP connector, including only the most common settings required for integrating with the application. If you toggle to an HTTP form view, you’ll have more configuration control and authentication options; however, this is not the same as a universal HTTP connector.
Remember to provide help text for custom or encrypted settings and fields through the metadata since this would be an app-specific field. Connector developers have full control over this type of field.
Comments
0 comments
Article is closed for comments.