Skip to content

Instantly share code, notes, and snippets.

@therabidbanana
Forked from mikekelly/0_README.txt
Created March 14, 2012 14:08
Show Gist options
  • Save therabidbanana/2036705 to your computer and use it in GitHub Desktop.
Save therabidbanana/2036705 to your computer and use it in GitHub Desktop.
A potential new version of hal
I've been playing with the idea of combining the data array defined in application/collection+json
(http://amundsen.com/media-types/collection/format/) with hal links for templated data.
Seems like a good way to keep the media type lightweight while allowing the api to specify the fields
it would like passed to a given resource.
I haven't really given much thought to an xml variation, but I took a stab at it as well.
{
"_links": {
"ex:basic": { "href": "/bleh" }
"ex:search": { "href": "/search_for;{searchTerm}"}
"ex:widget": { "href": "/widgets",
"data": [
{"name": "name", "type": "string"},
{"name": "description", "type": "string"}
] }
}
}
<resource href="/" xmlns:ex="http://example.org/rels/">
<link rel="ex:basic" href="/bleh" />
<link rel="ex:search" href="/search_for;{searchTerm}" />
<link rel="ex:widget" href="/widgets">
<data name="name" type="string" />
<data name="description" type="string" />
</link>
</resource>
@mikekelly
Copy link

Personally, I don't like the idea of using link as a templated write control - I'd much rather see this under a separate _controls and <control> ... </control> in JSON and XML respectively

@therabidbanana
Copy link
Author

That sounds reasonable. I can definitely see the advantage of separating those concerns. I started with a _template on the root json object that contained the data array, but wasn't sure whether it'd be preferable to add a new root element or to build on the existing ones.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment