The document discusses new approaches to hypertext and REST APIs in a mobile-first world. It proposes using JSON Hyperschema to define self-describing APIs and objects that can be interpreted across different devices through custom components. This allows the backend to remain the same while the frontend is laid out differently for each client type, enabling data-centric design on the server and render-focused clients.

1. Israel Shirk
Right now: Mad scientist, Ultra Runner, Backcountry
Skier, Performance Architect @ Scentsy (starting
Monday), CTO @ Zerrtech, and a bunch of other stuff

2. Ok, it’s really “New approaches to hypertext and REST in
a mobile-first world

3. Old internet: Homogeneity (except you-know-who)

4. New internet:
Shimmable homogeneity on the browser
Tablets!
Phones!
Desktop Applications!
Web Applications!
Embedded Devices!

5. Background:
What is “hypertext”?

6. Background:
What is “hypertext”?
Google:
“A software system that links topics on the screen to related
information and graphics, which are typically accessed by a
point-and-click method”

7. Background:
What is “REST”?

8. Background:
What is “REST”?
Martin Fowler:
Level 0 to Level 4

9. it: https://martinfowler.com/articles/richardsonMaturityModel.html

10. POX: Plain Old Xml (or JSON)
(Yeah, I’m saying your REST API ain’t REST)

11. Skip a few: Rest Level 3
Hypermedia Controls

12. Skip a few: Rest Level 3
Hypermedia Controls
(HATEOAS)

13. HATEOAS:
I hate operating systems?

14. HATEOAS:
Hypertext As The Engine Of Application State
Great example: HTML w/o JS.

15. New world order:
HTML does not always translate across devices
the way we want it to!
(dangit)

16. Solutions?
REST L4 in other forms,
interpreted on device
(like… a compat layer in-browser,
NativeScript, Electron, React Native, …)

17. Solution I’m using right now?
JSON Hyperschema (with nonstandard extensions)
Alternatives?
VND is most popular, others are out there but rarer

18. Why JSON Hyperschema?
It’s made for this problem: self-describing APIs
and objects.

19. Example:
{
"$schema": “http://json-schema.org/schema#",
“type”: “person”,
“X-name”: “Israel”,
“links”: [
{
“rel”: “profile”,
“href”: “https://www.facebook.com/israelshirk"
},
{
“rel”: “hubgit”
“href": “https://github.com/israelshirk"
}
]
}

20. Declare as JSON schema:
{
"$schema": “http://json-schema.org/schema#",
“type”: “person”,
“X-name”: “Israel”,
“links”: [
{
“rel”: “profile”,
“href”: “https://www.facebook.com/israelshirk"
},
{
“rel”: “hubgit”
“href": “https://github.com/israelshirk"
}
]
}

21. Define type of object
(technically the RFC doesn’t allow this but…
Open source to the rescue!)
{
"$schema": “http://json-schema.org/schema#",
“type”: “person”,
“X-name”: “Israel”,
“links”: [
{
“rel”: “profile”,
“href”: “https://www.facebook.com/israelshirk"
},
{
“rel”: “hubgit”
“href": “https://github.com/israelshirk"
}
]
}

22. Custom extensions start with X- to be mostly in-line with standard
{
"$schema": “http://json-schema.org/schema#",
“type”: “person”,
“X-name”: “Israel”,
“links”: [
{
“rel”: “profile”,
“href”: “https://www.facebook.com/israelshirk"
},
{
“rel”: “hubgit”
“href": “https://github.com/israelshirk"
}
]
}

23. Links to indicate paths that can be followed
{
"$schema": “http://json-schema.org/schema#",
“type”: “person”,
“X-name”: “Israel”,
“links”: [
{
“rel”: “profile”,
“href”: “https://www.facebook.com/israelshirk"
},
{
“rel”: “hubgit”
“href": “https://github.com/israelshirk"
}
]
}
http://json-schema.org/latest/json-schema-hypermedia.html#rfc.section.5

24. We can then start doing really fancy stuff:
{
"$schema": “http://json-schema.org/schema#",
“type”: “person”,
“X-name”: “Israel”,
“X-profile-name”: “israelshirk”,
“X-Friends”: { “$ref”: “/{profile}/friendlist” },
“links”: [
{
“rel”: “profile”,
“href”: “https://www.facebook.com/{profile}"
},
{
“rel”: “hubgit”,
“href": “https://github.com/{profile}"
},
{
“rel”: “save”,
“href”: “/{profile}”
}
]
}

25. Critical factors:
Easy-to-use interpreters.
Check out:
Mozilla’s React-Jsonschema-Form (I’m a rabble-rouser there)
Angular-Schema-Form (schemaform.io - just a bug fixer here)
JS lib for JSON hyper schema validation. I have a fork…. Somew
Then: Custom components for your object types!
Webcomponents are essential here.

26. eact-Jsonschema-Form: https://github.com/mozilla-services/react-
function PageLayout(props) {
const {children, schema} = props;
return (
<div class=“root”>
<!— This is the root page element. Children of the schema go into children below! —>
{children}
</div>
);
}
render((
<Form schema={schema}
fields={ { “page-layout”: PageLayout } } />,
), document.getElementById("app"));

27. eact-Jsonschema-Form: https://github.com/mozilla-services/react-
function PageLayout(props) {
const {children, schema} = props;
return (
<div class=“root”>
<!— This is the root page element. Children of the schema go into children below! —>
<div className=“col-xs-12”> <Form schema={schema[‘X-header’]} fields={fields} >
</div>
);
}
let fields = { PageLayout: PageLayout }
render((
<Form schema={schema}
fields={ fields } />,
), document.getElementById("app"));

28. u can do things like this, and each client will have an appropriate r
laid out differently by device type - but all from the same backend
{
“type”: “page-layout”,
“properties”: {
“header”: {
“type”: “array”,
“items”: [
{ “type”: “header-item”, “title”: “Click me!”, “links”:
[{ “link”: “/clickme” }]
}
],
},
“body”: {
“type”: “person”,
…
}
}
}

29. End result?
Data-centric wonderfulness server-side,
render-centric focus client-side!
Next steps?
Integration into nginx+lua+memcache for ref resolution,
like Varnish/Akamai for ESI
Add more gif (spoken as spelled)
Public code samples