Monday, September 2, 2013

API Design Technique for Web Application - Part 1

We are in the process of releasing our new web application, COIL, and are working on how to allow users to get their data. COIL is a complete sensor to server development system that enables developers to display data from Zigbee devices in a web page. Users can create an account for free and customize the display of the data. On the back end, COIL receives the data from Gateways and communicates with the devices. We sell COIL as both a single tenant application (one server = one organization) and also as a multi-tenant application (one server supports thousands of users, each with their own data and configuration).

COIL System Architecture

We use a MySQL database instance on Amazon RDS to hold our data. It's very cool. This is in a Virtual Private Cloud along with the application servers hosted on Amazon EC2. So everything is behind one big firewall, with very limited access in/out. For a single tenant system everything is dedicated to that client; one cloud instance only has that one company's data. For multi-tenant systems everything is shared to support thousands of users.

API Goals

One of the goals of COIL is to allow users to access their data via an Application Programming Interface (API). There are a few ways to implement this, all with their own challenges. The goals of our API are:
  • Easy to use - easy to pull into an application.
  • Multitenancy support - support different users
  • Secure - one user should not see a different user's data
  • Implementation independent - allow us to change schema etc. without breaking API
  • Isolated - prevent a user from bogging down the database server.
  • Cross-platform - not tied to Windows, Mac, Linux, etc.
  • Scalable - handle millions of rows

API Design Techniques

So we are evaluating different API approaches, and these have been mentioned:
* Database Access - open up a port into our database
* SOAP - Remote procedure calls
* REST - the most popular approach right now
* Flat Files - like a good old fashioned CSV file

Each of these has pros and cons, which we'll get into more in Part 2.

No comments:

Post a Comment