hypermedia lightning talk

or, in defense of centralization of some computation

(but not all of it)

by Alex Moore-Niemi / @feminstwerewolf

(a) Hypermedia (b) (c) (d) (e) GraphQL
A distributed hypermedia architect has only three fundamental options:
  1. render the data where it is located and send a fixed-format image to the recipient;
  2. encapsulate the data with a rendering engine and send both to the recipient; or,
  3. send the raw data to the recipient along with metadata that describes the data type, so that the recipient can choose their own rendering engine.
  1. "traditional client-server style" is Option 1, and means you only get what the server can render for you. GraphQL by itself fits in here, by putting a declarative interface on that rendering of data.
  2. Flash and Java applets are examples of Option 2. Obvious downsides: big over the wire, compatibility issues on the client. Basically extinct.
  3. RPC schemes that work by sharing header files (declarations) fit in Option 3, and so does Protobuf if you squint a little.
REST provides a hybrid of all three options by focusing on a shared understanding of data types with metadata, but limiting the scope of what is revealed to a standardized interface.

How do the server and client share understanding of data types?

Profiles, and registered media types.

Where do we get our standardized interface?

Our types, and our protocol.

But HTTP sux. :c

That's just one protocol. Don't let it box you in! (Also: no it doesn't.)

The model application is therefore an engine that moves from one state to the next by examining and choosing from among the alternative state transitions in the current set of representations.

How can we expose alternative state transitions in the current set of representations?

Hypermedia.

Hypermedia is defined by the presence of application control information embedded within, or as a layer above, the presentation of information. Distributed hypermedia allows the presentation and control information to be stored at remote locations.

so when might I want hypermedia?

When you have relatively little control over your clients, ie., can't expect them to update (mobile).

When you need properties like dynamic dispatch (associating an implementation with an operation) and dynamic binding (associating a name with an operation) in your program.

what are the tradeoffs?

Hypermedia requires the client to work with a certain granularity of programmatically generatable interaction units.

This would make working with Storyboard driven development in iOS difficult and maybe impossible.

In Android, activities need to be declared in the manifest at compile time, but fragments could be generated during runtime.

Our new mental model: Graphs

  • The server has a canonical superset of all possible application states it recognizes how to move through as a graph (every state is a node, and has edges to other nodes).
  • The client can rearrange any useful subgraph of those states it wants and make it available to the final key ingredient: user input/intent.
    • think of the server's graph as black, and the client's graph as red

Importantly, the client can request different sized "graphs" based on a set of tradeoffs like no network requests vs flexibility.

Want to minimize requests? Grab the biggest possible representation of application state with controls embedded of other potential application states, cache it, and move on.

Want to allow flexibility? Grab the smallest representation of application state with minimal controls linking (referencing, like reference types) to other potential application states.

stuff hypermedia does not solve* changing program data schema

stuff hypermedia does solve changing program topology

* if the client supports meta-programming or polymorphic representation of untyped data (like maps) hypermedia can solve this problem. yes, static langs can be meta-programmed. no, i have not lost my mind. 😅

some use cases of topology changing

  • introduction of a promotional element
  • changing terms and services or other notices
  • new selection criteria
  • retiring a workflow
  • adding a new workflow

All of these correspond to adding new nodes or edges to our graph. Done right the "hypermedia way" these can be done without the client needing to ever release a change.

this means:

  • clients can respond to API changes, not be broken by them
  • business logic is centralized, thus consistent
  • clients can focus on the user, not the server

😑 idgi...

Check out my extended presentation on hypermedia, discuss in #rest on freenode, or if all else fails, ask me. 😁