[Update 7/27/16: The Cronote Reminders iPhone app is no longer available but may return in the future.]
Some would ask why such a model is necessary. The simple – and powerful – answer is that we use the same Java POJOs for our REST API, our reminder-timing program, our website and our iPhone app. The website and iPhone app share the same code that calls the REST API.
The Cronote System is coming along well, and while we have our core timing logic down, there are several areas where we’d like to improve.
None the least of these is a central REST API for registration, logins, and, of course, cronote scheduling! While working on the iPhone App, it was clear that having separate gateways for the website and mobile apps made maintenance a huge issue.
REST stands for Representational State Transfer, and it basically means that all devices can communicate with cronote using the same protocol that is used for web pages (HTTP). Many other social media sites (like Twitter) use a REST interface to provide developers access to their system.
Our grand vision is to allow anyone to use our API to perform timed tasks, even beyond text messaging. It’s a lofty ambition, but it’s why we’re so excited to be working on cronote in the first place.
A lot of the structure for the main Cronote site came from Joshua Porter’s book, Designing for the Social Web. His work highlights the importance of a user’s initial experience. He points out that being able to try a service without a commitment assures potential users of the quality and reliably of the service. We agreed with this assessment, and added the ability to send an anonymous cronote right from our main site.
Of course, we’re concerned about robots (aka spam bots) scheduling cronotes. We’re taking measures to block spammers, as well as developing a “do not cronote” list for users who do not wish to receive anonymous cronotes (or cronotes at all).