REST

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.

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. 

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

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.