Architecture of Preferences and Data

From wiki.gpii
Revision as of 00:50, 3 April 2012 by Colinbdclark (talk | contribs)
Jump to: navigation, search


The GPII Personalization Framework takes a unique and powerful approach to data modelling and interoperability. The philosophy of this approach is to enable developers to represent data (such as user preferences) in the formats and structures that best suit their needs and implementation constraints. Eschewing the typical "my way or the highway" mode of data schemas, the GPII Personalization Framework leverages work developed for Fluid's Infusion application framework to easily adapt and transform data structures as needed.

The Preferences Server

The GPII Preferences Server is designed with a RESTful approach. REST, which stands for Representational State Transfer, is not new or obscure; it's actually the Web's architectural philosophy. In the RESTful approach, Web services are modeled as series of Resources, each with its own unique URL. Resources represent the content of the Web service, and are distinct from the many Representations, or formats that those Resources can be presented in.

In the case of the GPII Preferences Server, the primary Resource in the architecture is the user and their preferences. These will be identified by a URL such as:<anonymous user token>/preferences

The Preferences Server will support multiple Representations of a user's preferences, corresponding to particular formats and structures that are optimized for distinct use cases and implementations. While the server will indeed provide a standardized JSON Representation, consisting of the preferences mapped as flat key-value pairs that correspond to the AccessForAll preferences registry, there will be other formats. For example, a more terse and hierarchical JSON structure suitable for the high-performance processing and interchange requirements of the GPII Personalization Framework. One can even imagine HTML Representations of the user's preferences, enabling them to review the preferences they've set and edit them accordingly.

<example of flat and hierarchical preferences> In each case where the the Preferences Server exposes a particular data Representation (in JSON format), there will also be an accompanying "schema" or map, describing how data structure corresponds to the underlying AccessForAll preferences registry. This will ensure that multiple formats can coexist harmoniously; each Representation will be self-describing, ensuring that implementations can easily understand the format and its meaning. Here's an example:

<example of preferences schema>

In this way, the GPII Preferences Server takes advantage of RESTful principles and self-describing Resources to ensure that we can widely interoperate, supporting the diverse needs and requirements of implementers.

The Role of JSON