In a previous post, I wrote about using a Freemarker macro to dump a Freemarker container to JSON. That’s nice, but it limits you because macros dump the content directly to the page. It would be better to use a function. I tweaked the original macro to convert it into a function. The main thing to note was that instead of using assign, you need to use local. If you do not, the recursive function calls will step on each other’s variables.
Kind of a random post, but at work we’ve been trying to find a good way to dump a Freemarker object to JSON. I finally found a nice solution online, but it wasn’t even described as having the ability to do what it does, and now I can’t find the source of it. Hopefully this will help someone else out in the future, and if this code looks familiar, please let me know where it’s from so I can cite the source properly.
The following code will take a Freemarker sequence, hash, or collection (or a mixture of all three) and dump the contents to the page as JSON. It may work with other Freemarker data types as well, but I have not tested it. It’s currently a macro, but I think it would be fairly easy to convert it to a function as well.
The fourth and final part of this series is focusing on using the Slim Framework’s middleware functionality to validate (to a degree) RESTful API requests. This post will show how to add a simple API key to the requests. There is obviously more one could do, like having a secret key (which would not be passed to the server) to encode some data to further validate the user, but a simple API key is a good first step.
Now, the word middleware may conjure up a lot of Dilbert-type images, but Slim’s middleware is simple and highly functional. To start, let’s modify the route:
// The old route
// $this->app->get('/get/:id', array($this, 'getItem'));
$this->app->get('/get/:id/:key', array($this,'verifyKey'), array($this, 'getItem'));
The final topic, How to use Slim’s middleware support to limit the API to valid users, is going to be the subject of Part 4. This post was lengthy enough without diving into that subject.
How to use jQuery to do Puts and Deletes
Since modern browsers do not support PUT or DELETE directly from a form, you have to use their support of XMLHttpRequest, and probably the easiest way to do that is with jQuery. To check your browser’s support of XMLHttpRequest, there is an excellent array of tests available at this site.
I was playing around with Slim Framework recently, and decided to write-up another article about it, since it’s such a breeze. The original post highlighted how simple it was to get your Get, Post, Put, and Delete all wired up and ready to do work. This post will show how to create a little class that utilizes Slim and could serve as a launching point to building your own RESTful API. I’m planning one last post on Slim which will show how to use jQuery to do Puts and Deletes (since modern browsers typically only support Gets and Posts), make the API responses more useful, and how to use Slim’s middleware support to limit the API to valid users.
Time for a QuickNap
To make things more manageable, I created a new class for the API implementation. It’s bare bones at the moment and takes the DB connection information as arguments for its constructor.
In the first post in this series, I covered a personal project: LG Console. In this post I’m going to discuss a project I worked on earlier in 2012 for Jenkat Media, Inc., a company I helped co-found back in 2007.
With JenkatGames.com we have had a long-standing problem: we don’t really have a good idea on how much a new user is worth to us. Much of our user base does not register with the site, and since the content is all free, there’s no transactions to track. We decided to start tracking various actions, starting with page views, that generated small amounts of revenue. To that end, we decided on deploying a small REST service on an external host and having our server hit it when a trackable action occurred.
Cloning Your App
Once you have your app up and running on AppFog, you are able to clone it. There would be a variety of reasons to do this, but two that stick in my head are: offer higher availability (which I’ll touch on shortly) or providing different levels of service for different types of customers. Perhaps I would want my paying customers on a more powerful instance at uber.ericbrandel.com, while the free customers are on a less powerful and less costly instance at free.ericbrandel.com.
Adjusting the amount of resources available to an app is amazingly easy. Just slide the Instances and Memory Quota sliders and set your desired levels. After adjusting, your app will restart, and your code will be copied to each instance, each one running with their own set amount of memory.
One of the podcasts I listen to on a regular basis is The Cloudcast. Last month they had an interview about VMWare’s Cloud Foundry push. Cloud Foundry is the “Open Platform as a Service Project”. As with other PaaS offerings, like the Salesforce.com acquired Heroku, the idea is to provide the platform stack you need, without having to worry about the underlying hardware, software, storage, OS, etc. To use the popular LAMP stack as an example, it really doesn’t matter what version of Linux is being utilized for most LAMP development, and the same is true for Apache HTTP Server. What you want are updated, patched, and configured versions of the OS and web server. A proper PaaS abstracts away the server infrastructure. With Cloud Foundry the attempt is also made to make moving between various PaaS providers as easy as possible, with standard APIs, service, and language support. The goal is to introduce true cloud application portability.