RESTCat is a RESTful comprehensive activity tracker. It is secure database for storing and accessing sensitive information such as personal health information (PHI).
RESTCat is specialized server framework to manage data, identity, security, transactions. Example applications include:
The sever’s generic transaction engine, however, means that it can be applied to a wide variety of tasks.
Although designed for health information, the server’s generic transaction engine, however, means that it can be applied to a wide variety of tasks. (If you are not building a health-related application, then you may want to turn off some of the defaults.) If your goal is to build high quality, reliable data that are easy to sort and visualize later on, then RESTCat may be a tool that will suit your requirements.
RESTCat works with “object/non-relational” database, while providing some restrictions around:
With RESTCat, you can define required fields, disallow fields, and validate the structure of fields in the otherwise free-form “wild wild west” of object storage systems.
Submitting objects to RESTCat requires authentication, hence a submitter must have a valid account.
When RESTCat’ settings are set to RESPECT_SOCIAL_GRAPH=True, then reads/writes can only occur when a relationship exists between users.
RESTCat also understands Open Mobile Health Exchange OMHE the Microsyntax natively. (See http://code.google.com/p/omhe for more information on OMHE Microsyntax.) This means if you send a transaction of type ‘omhe’ (ttype=omhe) and ‘text’ containing a valid OMHE string, then RESTCat will parse and validate the information for you. So if ‘text’ has the value ‘bp120/80p60#2010701:073759z#tx-5’, then the resulting object created will automatically have all the blood pressure information validated and parsed.
The actual date & time the blood pressure reading was taken will be captured, as well. This is known as the event datetime and the event timezone offset. (e.g: ‘ev_dt=2010701:073759z’ and ‘ev_tx=-5’.)
Note that users, user authentication, and the social graph are controlled by a RDBM system of the user’s choice (as long as its supported by Django) whereas the object (transaction) data is stored in an object server such as MongoDB.
RESTCat is a transaction engine with a RESTful API. It can be described as a social object server because it can disallow database reads and writes based on a social graph (or lack thereof).
RESTCat is a RESTful API server written in Python and Django that uses MongoDB, to store transaction data. RESTCat is designed to serve as a back-end for self-tracking, time-tracking, population management, auditing, situational awareness, and health gaming applications. The server’s generic transaction engine, however, means that it can be applied to a wide variety of applications that involve “people tracking”.
(If you are not building a health-related application, then you may want to turn off some of the defaults.) If your goal is to build high quality,reliable data that are easy to sort and visualize later on, then RESTCat may be a tool that will suit your requirements.
RESTCat works with “object/non-relational” databases such as MongoDB, while providing some restrictions around:
RESTCat, uses MUESLI as a transaction data standard. This specification defines required fields, disallows fields, and validate the structure of fields in the otherwise free-form “wild wild west” of object storage systems.
If you need to store information in RESTCat that is not defined in MUESLI, then all you need to do is to pass a extra_fields a JSON dictionary of all the additional name/value pairs you want attached to your transaction.