Hypermedia CMS Client

Convener

Dave Goldberg (@davidgoldberg) https://twitter.com/davidgoldberg

Attendees

Matthew Bishop, Brendan Gualdoni

Notes

General concept was a CMS that would allow non-technical (or semi-technical) users to construct templates that would be consistent across multiple APIs that leveraged common media-types and profiles.

Discussion first focused on clients dynamically understanding structure. Point made that this is already being done successfully in a number of places:

• Google using JSON-LD in GMail
• NewsML
• Facebook OpenGraph
• etc...

This shifted the discussion to the idea that hypermedia is more than just understanding a structured piece of data. Hypermedia APIs include the concept of affordances, which can drive dynamic behavior in clients.

Discussion moved to real-world needs, and we focused on a hypothetical e-commerce application.

A pain point exists because page management of complex applications drives a lot of custom behavior. Pieces of a single page that need to talk to each other, and link behavior that varies from changing a single component of a page, to reloading the entire page, to submitting a form, etc.. In addition, this is always getting changed by business needs. Could Hypermedia offer a path to a more adaptable client?

Discussion moved to how this might work. First we articulated the parts of a dynamic page in hypermedia terms. It came down to 2 basic elements. A dynamic page is comprised of:

1. Individual resources
2. Each of those resources provides affordances to possible actions or subsequent behavior.

A server side 'CMS' layer could act as a generic bridge to the front-end client by:

1. Providing awareness of resources to each other
2. Providing an event framework, based entirely on affordances that determines the resource 'dance' on the page as a result of user interaction.

At a high level this layer would be either a script or a visual interface. It would list all the resources on a given page, and for each resource list all of the affordances. Then, via script or interface, it would 'connect' an affordance trigger event on one resource to one or many affordance 'action' events on one or more resources that get impacted. The result might be a configuration file or just that same script being used to drive on page behavior.

The advantages of this approach are:

• Less customization on the client

• Ability to interact with multiple data sources, as long as those data sources use known media-types and profiles
• Adaptability to change.