Using Mondor API in consumer applications

by kristijn 24. September 2013 02:15

Today we celebrate the first 3rd party desktop application which is using our API services at back-end.

Here it is - a Windows 8 currency rates converter by Dmitry Kirsanov.

The application is free and ad-free, so you are welcome to install it for those special moments when you need to check “whether it’s just your app or our service”.

A few notes about this application and best practices for writing mobile and wide distribution applications:

  • Never use Mondor API directly from a mobile / desktop application.
    Always use your own back-end, which is connecting to Mondor API. There are few reasons for that - to not overload our servers and to not expose the access key.

    While we are serving thousands of websites and server applications with millions of requests per day, they are relatively easy to handle - the same IP address, the same web services / WCF / WebAPI client, the same connectivity. Mobile and desktop applications usually do not have very good connection, may drop it in the middle, may be slow to respond and behave in the way that it may create problems for the service. When the client creates problems, the access key may be suspended. When the access key is suspended, your mobile application stops functioning.

    The idea of not exposing your access key is quite obvious - when we see that someone else is trying to use your key, the key is disabled and you may request new one, unless it was you who published it. Nevertheless, it means downtime for your service.
  • When connecting from your custom back-end (a proxy between your clients and our API) try to use WebAPI or WCF, instead of classic XML Web Services. You will see that traffic and response times are better.
  • Contact us if you have questions - our support is always willing to assist, especially if it helps to prevent problems in the future.
  • Ensure that your WCF client supports data compression. This will help you to make your applications way more responsive.
  • Use asynchronous calls for better responsiveness, even between your application and your service.
  • Cache data, it’s better to save traffic than server memory.

 

The mentioned desktop application, as well as its Windows Phone counterpart, are using their own servers with data compression and authentication mechanisms, and that means, that even if our service would be inaccessible, the application still works. Besides, if the application service doesn’t work, it doesn’t mean that API is down. Such independence provides a better environment for both yours and our customers.

Page List

Month List