Rest Adapter

Architecture

Functionality

The REST Adapter handles all endpoints as they are originally exposed and does not modify any of the APIs provided by the application that you are connecting to.

Channel selection

The dynamic endpoint name is assigned to each REST adapter sender channel. The initial task is to search for an active REST API channel whose dynamic filter pattern corresponds to the incoming message. The dynamic filters enable selection based on matching URL parts or message content (currently only available for JSON, and XML). This functionality enables the processing of different REST services using either single or individual channels.

Message format

The REST adapter can currently process message formats such as XML, JSON, and Unstructured Text. If the request data format is JSON, the adapter has the capability to convert the message into XML, facilitating the client system's complex processing of the message. Moreover, the adapter can convert the incoming message payload's encoding to the client's default. The character set can either be specified manually or determined dynamically from the HTTP header or message content.

In a synchronous scenario, the client system returns a message, which may contain operation and message type. These can be stripped off if necessary. The response message can be converted back to JSON from XML if required. Additionally, the character set can also be converted back.

Extracting information from the URL

Predefined and custom adapter-specific variables can extract parts from the incoming URL. These variables can be employed as dynamic client message variables, conveying this information and determining the client operation and message type.

Extracting information from the HTTP operation

To define the requested operation on the REST resource, the REST protocol utilizes the four fundamental HTTP operations: POST, GET, PUT, and DELETE. This information can be placed into the client message variables for subsequent use or to determine the operation and message type. Ordinarily, the HTTP operation maps directly; however, it is feasible to extract the desired operation from the URL, HTTP headers, or message content.

Capabilities

• SUPPORTED HTTP METHODS: GET, POST

• API FILTERS: DATE FILTER, and PAGINATION FILTER Should be present with the API and other specific filters should be mentioned if any

• MEDIA TYPES: The supported media types are APPLICATION_JSON, APPLICATION_XML, TEXT_HTML, APPLICATION_FORM_URLENCODED, TEXT_XML, MULTIPART_FORM_DATA

• HEADERS: Required headers should be given clearly in the API Documentation.

• AUTHENTICATION MECHANISM: We support only the GET and POST Auth mechanisms.

• RESPONSE: Data with standard http response code like information response (100-199), Successful response (200-299), Redirect response (300-399), Client Error Response (400-499), Server Error response (500-599) The response should be in XML/JSON only and for POST APIs, a flag is needed to differentiate success and failure records.

• REQUEST: Api with only support JSON, and XML formatting request

• RESULT: In a result, the flag should be present either TRUE or FALSE, 1 or 0, any other clear capture of SUCCESS or FAILURE

• IMPORTANT NOTES: ALL APIS SHOULD BE SSL CERTIFIED, STANDARD REST APIScan ARE PREFERRED