2.1 Web Service REST Design
The Thru REST Services API adheres to the following points of the REST paradigm:
Interaction between client and server is semi-stateless (no connection is established, but the session is used to authorize user)
The API leverages existing features of the HTTP protocol (URL, headers, request body), not requiring any special messaging protocol/library (SOAP or RPC)
Platform-independence (client can be running on any operating system)
Language-independence (client can be developed in any language of preference)
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
NOTE: Please 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 formats are:
o Accept: application/xml
o Accept: application/json
Response data are not bound to a specific format (e.g.: SOAP receives and returns data always in XML).
Though the standard data exchange format used in REST architectures (as well as in the Thru API) is XML, the Thru API also supports JSON and, in fact, 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 formats:
API endpoints are designed around resources (e.g.: files, messages) that are identified by uniform URIs.
For instance, 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:
o GET (Retrieve resource/resources)
o POST (Create a new resource)
o PUT (Update an existing resource)
o DELETE (Delete an existing resource)