A Better Cloud Printer II API interface

21.45 in a, api, better, cloud, ii, interface, printer

This post continues from my earlier post:

• Looking for a better cloud receipt printer.

• A better cloud printer I.

The API definition

So I have got my software stack on a drawing board, next is to make it happen with actual code. RestFul API requests are defined in JSON format:

// this is the very 1st API definition, print out something to a remote printer
{
  "sid"         :"asdfasdf",
  "secret"      :"13wd23d2323r",
  "apiversion"  :"2014-01-01",
  "service"     :"submit",
  "parameter"   :{
      "printerid"   :"asdf2323wd2e",
      "title"       :"xxxxxxx",
      "content"     :"xxxxxxx",
      "contentType" :"PLAINTEXT"
  }
}

  // Response
  {
    "jobid" :"xxxx",
    "status":"ok",  // in progress, fail, ...
    "printerid" :"xxxx"
  }
  

Will update the progress soon....

*Edit 2013-12-27

I have been working on this thing during the holiday season. The rough framework code for public API has been setup as follows:

Public facing software stack: Centos + Nginx + PHP + mySQL + GearMan
PHP libraries are:

• Luracast Restler - the framework handles RESTful requests
• Idiorm - ActiveRecord library. (When I am too lazy to write real SQL queries)
• Whole bunch of PHP utility functions I wrote in the past.

Although the rage is all about Redis and Node.js, I dont see a compelling reason to use the newer software stack. Call me old school:

• Print API data is strictly structured, saved to database as json encoded string.
• RESTful, no state between requests.
• The API will return right after been fired.  (before the actual printer output is finished)
• Client Callback url for job status update.

Why not Redis/Node/Mongo/Riak/Erlang/whatever?  With Nginx + PHP-fpm, this setup should easily handle 100+ requests/sec on a very cheap VPS(by cheap,  I mean $5 per month).  And I dont see it reaching that limit with a deployment of less than 2000 printers.  If I ever run out of server capacity, the fortune is on my side.  I should already be making enough money to upgrade the servers.

For the actual worker process that handles individual request processing, I might consider something runs on top of libev as daemon.  Could be Node.js or Python Twisted, will leave that for later decision.

*Side note: I am thinking about opensource the entire thing on Github, anyone interested?
If someone can help manage the repo, Ill make it happen.