Web service REST design

The MFT FS REST Services API follows these REST principles:

• Client-server interaction is semi-stateless. While no persistent connection is maintained, a session authenticates the user for each request.

• The API leverages existing features of the HTTP protocol (URL, headers, request body), not requiring any special messaging protocol/library (SOAP or RPC).

• This system is platform-independent. The client can operate on any operating system.

• The client can be developed using any programming language.

• The requirement for request format:

  Request body must be present in application/x-www-form-urlencoded format (Content-Type must be set to application/x-www-form-urlencoded) and request body in HTTP POST must be serialized as a standard query string: a=1&b=2&c=3&d=4&e=5

info

Do not pass parameters above on a URL as a query string, pass in a POST body.

The standard HTTP header Accept is used to define a data format that will be provided for the client in Response.

The currently supported format is:

• Accept: application/json

• Response data are not bound to a specific format (For example, SOAP receives and returns data always in XML).

Though the standard data exchange format used in REST architectures and the MFT FS API is JSON, the MFT FS API also supports XML and can be expanded to support other formats in the future.

The data format in response is determined by the standard HTTP headers Content-Type.

The currently supported format:

• Content-Type:application/json

• API endpoints are designed around resources (For example, files, messages) that are identified by uniform URIs.

For example, all API endpoints built for dealing with file system objects start with the same URI https://[ThruWebServer]/REST/[version]/FileSystem.

The type of action to be performed on the resource is designated by passing standard HTTP verbs:

• GET (Retrieve resource/resources)
• POST (Create a new resource)
• PUT (Update an existing resource)
• DELETE (Delete an existing resource)