Last active
December 29, 2015 00:39
-
-
Save bradgessler/7587671 to your computer and use it in GitHub Desktop.
JSON is too verbose for hypermedia APIs. HON (Hypermedia Object Notation) preserves the readability and implicit data structure of JSON while with the addition of line attributes for URL and pagination metadata. From http://bradgessler.com/articles/hon/
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
{ | |
name: "Todo List", | |
items(href: '/lists/1203/items', next_href: "/lists/1203/items?page=2"): [ | |
item(href: '/items/1'): { | |
description: "Pick up pizza", | |
status: "completed" | |
}, | |
item(href: '/items/12'): { | |
description: "Eat pizza", | |
status: "non_started" | |
} | |
] | |
} |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I would limit the key attributes (
{key(attributes): value}
) to hrefs that help HON client load and navigate datasets from the service.I'm trying to avoid nasty metadata structures that are emerging in JSON hypermedia standards that would make this look like:
When words like "collection" emerge within a data structure like JSON I feel like we're doing it wrong. I've also seen a number of JSON hypermedia standards preface keys with an
_
to denote meta data (e.g._href
) which also feels like an anti-pattern.Interesting, look what happens when my first example is implemented as Haml XML:
I notice a few problems:
<items/>
attribute contains a collection of<item/>
's%link
elements feel too generic and contrived for this example. They would make more sense if the links were attachments like%link{rel="attachment" href="pizza_receipt.pdf"}
.Interesting how the development community at large might be blowing up JSON into the complex monstrosity that XML was in the early 2000's.