Difference between revisions of "Architecture of Preferences and Data"

From wiki.gpii
Jump to: navigation, search
Line 16: Line 16:
 
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.
 
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>
+
<pre>
 +
example of flat preferences format
 +
</pre>
 +
 
 +
<pre>
 +
example of hierarchical preferences format
 +
</pre>
 +
 
 
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:
 
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>
+
<pre>
 +
example of preferences schema
 +
</pre>
  
 
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.  
 
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 ==
 
== The Role of JSON ==

Revision as of 00:51, 3 April 2012

Overview

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:

http://preferences.gpii.net/users/<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 preferences format
example of hierarchical preferences format

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