Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Representational State Transfer (REST) is a software architecture style consisting of guidelines and best practices for creating scalable web services. REST is a coordinated set of constraints applied to the design of components in a distributed hypermedia system that can lead to maintainable architecture with an impressive performance.

Field (Account) Information

While configuring the Source or Destination of a Template or Transaction, you need to create an account to configure your application with Adeptia Connect. While creating an account, you need to specify the location from where Adeptia Connect will access the data.

Click  to add an account.

Specify the following information for a REST application while using it at the source side:


Specify the following information for a REST application while using it at the destination side:



Field Name

Description

Account Name

A short, descriptive name so you can re-use this account in the future.

HTTP Method

The methods used to receive, send, or store the file. When using REST, you can use either GET, POST or PUT, depending on what the application API supports.

GET is used to fetch data. POST is generally used to create or store new data, while PUT is used to update existing data.

Some considerations when creating the Source REST APIs include:

  • Depending on the API, POST and PUT at source may be used not only to send data but also to receive the data (response after executing a POST or PUT request).
  • Request Body field appears when POST and PUT methods are used at the source side. This is where you enter your actual data in the specified format (Content-Type).
  • Content-Type field is not visible with GET method.

Some considerations when creating the Target REST APIs include:

  • Do you explicitly name your URL objects you create, or do you let the server decide the name? If you name them, then use PUT. If you let the server decide, then use POST.
  • PUT is idempotent, so if you PUT an object twice, it has no effect. This is a nice property that makes one use PUT when possible.
  • You can update or create a resource with PUT with the same object URL.
  • With POST you can have 2 requests coming in at the same time making modifications to an URL, and they may update different parts of the object.

URL

Endpoint URL of the REST web service. For example: http://example.com/post/ or http://example.com/script.php?method=post_data&cust=123.

Header Parameters

Click Add and enter the header parameters if needed by the target application.

REST APIs use the HTTP standard. Therefore, any REST call headers are in fact HTTP headers. They define the operating parameters of the transaction, the so-called metadata. It is considered the bad practice to transmit actual data as a header field. Ideally, since each endpoint represents a state transfer, custom headers should only be used for things that do not involve the name of the resource (should be passed in the URL), the state of the resource (should be passed in the body), or parameters directly affecting the resource (should be passed as URL parameters). That leaves only true metadata about the request in custom headers.

Enable Client authentication

When this is enabled, both server and client authenticate each other in such a way that both are assured of each others' identity. By default the server is always authenticated, verify the target's SSL certificate, before connection. Click My Account > Preferences and Settings > Trusted Certificates to first import the target certificate, before connecting to the target. Refer Managing Preferences and Settings section for details. 

Select the KeystoreThis field appears when client authentication is enabled. Select the required Keystore if you have already generated or imported it. Else, generate or import the required keystore. Refer Managing Preferences and Settings section for details. 
Post Data as AttachmentSelect this if you want the data to be transferred as an attachment. Else, the data is included in-line in the URL request.
Part Name

Part name used to identify data in a Multipart request. This is only applicable if you select the Post Data as Attachment option.

Authorization

Select this if the server requires authorization. Basic and Digest authorization methods are supported. As a user, you just need to select the Basic/Digest option, if required. The authentication method is then automatically determined, based on the target.

Digest Authentication communicates credentials in an encrypted form by applying a hash function to the username, the password, a server supplied nonce value, the HTTP method, and the requested URL.

Whereas Basic Authentication uses unencrypted base64 encoding.

Therefore Basic Authentication should generally only be used where transport layer security is provided such as HTTPS.

 User ID The user ID for authorization. Only applicable if Authorization is enabled.
PasswordThe password for authorization. Only applicable if Authorization is enabled.
PreemptiveSelect this option to send the authorization credentials, even without being requested by the target. Else, these credentials are sent after the target specifically requests them. Only applicable if Authorization is enabled.

 

Triggers

A Trigger specifies when a particular Transaction will start executing. While configuring the Source of a Template, you need to choose an event.  

Following triggers are available for REST at Source.

Trigger NameDescription
Receive DataReceives data from the specified source.

 

Actions

An Action specifies how the data will be transferred at the destination location. While configuring the Destination (Target) of a Template, you need to choose an action. 

Following actions are available for REST at Destination. 

Action NameDescription
Send DataSends the source data to the specified destination.
  • No labels