Earlier today a reader asked me to discuss using Parse.com on the server. I've blogged about Parse quite a bit, but always in the context of a web application (typically a mobile application). Parse.com has a full REST API that provides 100% of the functionality I've talked about before to any server-side application. In this blog post I'll demonstrate a few examples in ColdFusion, but certainly any application platform would suffice.

First off, let's discuss why you would want to integrate your server with your Parse.com application data. The docs provide a few reasons, two of which I think are big - uploading a significant amount of data and exporting Parse.com data. Specifically that last one could be vital for creating backups. (Parse could fail. It happens.) On top of that I can also think of other reasons.

To me, the biggest would be reporting. Parse.com's dashboard has a dataviewer, a rather nice one, but managers will want something a bit more formal. Also, you can't get an aggregate view of your data at a high level. The REST API would make all of this possible.

Let's look at a simple example of retrieving data. Parse has made their API as simple as possible. All URLs begin with a base value:


You then simply append to the URL based on the type of data you are getting. So for example, if I wanted to get "TipObject" data (see the related links below for a look back at my "CowTipLine" application) I'd use this URL:


You also have access to metadata like installations and users:


To retrieve data, you pass along two headers: X-Parse-Application-Id and X-Parse-REST-API-Key. As a reminder, you can find your application ID and REST API keys in the dashboard for your application.

Here is a quick demonstration of retrieving TipObjects.

And the result:

Retrieving one object is as simple as appending an object ID value to the URL:


Most likely though you aren't going to want to fetch everything. The REST API provides a very rich query functionality that lets you...

  • Do property matches and ranges (i.e. x=something or x gt something)
  • Retrieve nest data (this is optional and gives you better control over the size of data being retrieved)
  • Return just a count (note that, by itself, a count request won't limit the results, you need to ask for a count and tell Parse to return no objects)
  • Handle pagination

Consider the simple example below. It filters my TipObjects by the property howdangerous where the value is 1.

As you can see, the query value is passed as a URL variable named where. The value of this is a JSON-encoded string. If I were doing something very complex I'd create the filter as pure data and then convert to JSON.

I mentioned earlier that I'd consider reporting as the best use case for this feature. Let's consider a simple example. My application lets you report on the relative safety of a region on a 1 to 3 value. Using the Parse.com REST API I can ask for a "count" value on each of those values. Parse.com has a "batch" process where you can run multiple operations at once, but unfortunately it doesn't support GET operations. (I filed a request for this here: Support for Batch and Get) But since this is an aggregate report we can simply add a bit of caching so we are not constantly hitting the API. In this example I've added a cache for 0.1 of a day (which we all know is... um... something).

I built a simple chart to render this in manager-friendly bright colors.

Finally, how about an email report? You can imagine a scheduled task that, once a month, emails management a basic report covering the number of new users and data entries over the past month. Date filters are slightly more complex. Here is an example with a bit of white space in it to make it easier to read:

where = {

Note how I have to specify a type for the property. Here is a full example that emails the report for the month (and certainly you could change this to a daily, weekly, etc type report).