Fluent 2013 session - Implementing Hypermedia Clients: It’s Not Rocket Science
This was a very impressive session because it dealt with a generic concept - hypermedia client. The most common hypermedia form that we have known is web pages and the client for it is actually a web browser. However, there exists many other types of hypermedia and their corresponding clients. Specific types of hypermedia differ from each other in three aspects - structure semantics, protocol semantics and application semantics.
A web page is an XML in terms of structure semantics. It's transmitted using HTTP in terms of protocol semantics. And it uses CSS in terms of application semantics. Alternative hypermedia structures include CSV, JSON, YAML, etc. Alternative hypermedia protocols include WebSockets, XMPP, etc. Alternative application semantics include XSD, JSON-Schema, etc. All three of semantics are needed for any successful communication between client and server. This threesome (S-P-A) forms the essentials of communication over distributed networks.
Given the existence of various of forms of hyperdia transportation, it's pretty attractive to develop a generic hypermedia client that is capable of accepting, processing and responding to multiple types. Such a client is represented with a combination of H Factors. The H Factor of a media-type is a measurement of the level of hypermedia support and sophistication of a media-type. H Factor values can be used to compare and contrast media types in order to aid in selecting the proper media-type(s) for implementation.
H Factors in an HTML:
Support for embedded links (HTTP GET)
<img src="http://www.example.org/images/logo" title="company logo" />
Support for out-bound navigational links (HTTP GET)
<a href="http://www.example.org/search" title="view search page">Search</a>
Support for templated queries (HTTP GET)
The speak person described two types of hypermedia clients, human client and non-human client. Below are the pros and cons of both.
Advantages of hypermedia clients for humans
flexibility to support a wide range of non-breaking domain-level changes
- adding new display & input fields
- adding new resources/pages
- adding new link and form options (not new protocol options)
- changes in access control rules is “automatic” no access?no controls
- ability to separate “parsing” from “display”
- Most hypermedia tuypes keep clear separation bet
Drawbacks of hypermedia clients for humans
SoC can mean extra work for clients
Possibility of changes in server can limit UI opitons
Anything short of FHC risks client adaptability
-If client determines what to display, new fields will not appear.
- If client determines what transitions to support and in what order they appear, changes( add/move forms & links) may break the clients.
If the message format is unstable (breaking changes occurring), FHCs have no real advantage over one-off client coding.
Advantages of hypermedia clients for machines
- ability to hand off tedious work to “smart” machine
- Using “generic” media types makes it possible to use the same client code for several different tasks/projects
- Coding new tasks gets faster over time since the baseline code already exists
- Simple modifications in the server (order
Drawbacks of hypermedia clients for machines
- Making machines “smart” takes time, esp. for non-trivial tasks
- Some changes in message can brak clients (missing transitions, new fields, etc.)
- Some unsafe operations (POST/PUT/DELETE) may need human intervention anyways.
<input name="query" type="text" value="" />
<input type="submit" />