Optalitix Proxy API for CMS

Introduction

Welcome to the Optalitix Proxy API for CMS.The API has been built and customized for the benefit of UTB. If any aspect of the API could be improved, please let us know and we will make the appropriate changes.

Json API

Please see the JSON API for more details about the API methods supplied as part of this API. Soap and XML APIs are available upon request.

SDK

A client SDK can be provided upon request. This is built in C# code and makes use of the Open Source “RestSharp” library. This requires .NET version 4.0 or higher.

Console

The Console is intended to help with developing, testing and debugging the API calls. Everytime you make an API Call, the calls are logged on the Console. Use this for all testing and debugging purposes. For the sake of security the Console is usually disabled in production.

Environments

We usually provide three environments for our APIs:

• Development, for use by developers on their desktops.
• Staging, for use in QA and pre-production environments.
• Production, for use in production environment only

Security

Security Methods

The API employs three security methods:

1. HTTP Basic Authentication – to prevent unauthorized usage of the API. Only works when SSL is enabled.
2. SSL - to protect the confidential data of the API.
3. IP Whitelist – Only servers registered on our IP whitelist will be able to access the API to prevent unauthorized usage.

Comments

1. Basic Authentication and SSL will be used in all environments, including Development, Staging and Production.
2. The development environment will allow non-SSL connections but Staging and Production will not.
3. The Basic Authentication passwords will not be the same in all the environments. We will supply all relevant Basic Authentication passwords at the appropriate time.
4. IP Whitelist is used in Staging and Production but not Development.

HTTP Basic Authentication

HTTP basic authentication is implemented using the HTTP Authorization header. The format of the header is shown below:

Authorization: Basic [Base 64 encode of username:password]

For example, if the username is “test” and the password “testpass”, we can arrive at the correct header by taking Base 64 encoding of “test:testpass” which is “dGVzdDp0ZXN0cGFzcw==”. The HTTP header in this case will be

Authorization: Basic dGVzdDp0ZXN0cGFzcw==

API Best Practise

The client system e.g. online website should still be available when our API is down. API calls should be contained within try/catch blocks which log all exceptions.

API Performance

The performance goal of the API is that the API should return a response in 0.2 seconds at least 95% of the time under normal conditions. In practise we have achieved this performance goal 99% of the time for most of our customers. However network latency due to distance to the API client could mean that the perceived performance of the API is slower than the actual performance. To improve performance we can host the API in the same data centre or very close to the API client. This may incur additional costs.

Testing the API.

Fiddler 2 is a very useful tool for interacting with the API before commencing development. It can be downloaded using http://www.telerik.com/fiddler

All the API code in this document has been developed and tested using Fiddler.