Building Hypermedia APIs with HTML5 and Node

What Hacker News says

1. ethagnawlJun 2016
   REST in Practice[1], Building Hypermedia APIs with HTML5 and Node[2] and Designing Hypermedia APIs[3].

   1. https://www.amazon.com/REST-Practice-Hypermedia-Systems-Arch...

   2. https://www.amazon.com/Building-Hypermedia-APIs-HTML5-Node/d...

   3. http://www.designinghypermediaapis.com/

   thread
2. michaelsbradleySep 2012
   I'm not sure about a format just yet, but I'm fairly certain it would be a superset of edn (as opposed to imposing it on "plain old edn"). The Document Format spec for Collection+JSON is probably not a bad starting point:

   http://amundsen.com/media-types/collection/format/

   Seems like it could readily be adapted to edn syntax. But I find myself drawn to the RDF concepts underlying JSON-LD, and wonder if the C+J and LD ideas could be melded together.

   A solid exploration of the larger concepts involved in hypermedia controls can be found in Mike Amundsen's recent book:

   Building Hypermedia APIs with HTML5 and Node

   http://shop.oreilly.com/product/0636920020530.do

   The basic idea is that, per Fielding, HATEOAS is an aspect of REST that shouldn't be ignored. Standardized media types with well-defined hypermedia controls allow clients that understand those standards to make state transitions without having to "know other rules" that aren't contained in the representations themselves.

   Our web browsers do this all the time when we click on links and submit forms that we find in web pages. Based on the X/HTML standard, ours browsers (hypermedia clients) know what to do with links and forms, i.e. how to initiate the appropriate state transitions (build and run GET/POST requests) based on the markup semantics.

   Now, if a client is driven programmatically (i.e. not by a human reasoning about the appearance and purpose of a form-button labeled "login", etc.) then you need a bit more besides links and forms. This is where attributes like "rel" (for `a` and `link`) become important. There's been a lot of work in that area, e.g. Microformats and RDFa, among others.

   Show morethread
3. michaelsbradleyJul 2012
   If you are concerned with having your API conform to HATEOAS, HTML offers some clear advantages over JSON. Namely, HTML has well defined "hypermedia affordances", or "H Factors"; plain old JSON has none:

   H Factor

   http://www.amundsen.com/hypermedia/hfactor/

   Hypermedia-Oriented Design

   http://amundsen.com/articles/hypermedia-oriented-design/

   It's possible to develop and document a well-defined "semantic profile" for a hypermedia API that uses HTML as the base media type. For an example see:

   ALPS - Application-Level Profile Semantics

   http://amundsen.com/hypermedia/profiles/

   By leveraging some or all of the details of the API, machine-to-machine logic can be developed fairly easily. In his recent book Building Hypermedia APIs with HTML5 and Node, Mike Amundsen demonstrates an example of a "microblogging bot" that consumes an API conforming to the semantic profile detailed in the ALPS document. The bot (written in JavaScript), knowing only the semantics involved with registration and "create post" links/forms, and an entry point for the API, is able to signup and begin making posts.

   The interesting thing is that the precise implementation of the API is not important, e.g. whether it's written with NodeJS or PHP or Clojure or whatever. Also, from one implementation to another, the pages served by the API could vary in terms of the layout of the pages, CSS, etc. So long as the pages conform to the semantic profile, the bot should be able to work equally well with a wide variety of implementations.

   Regarding JSON, there are a number of attempts to develop hypermedia-rich media types on top of it:

   HAL

   http://tools.ietf.org/html/draft-kelly-json-hal-03

   JSON-LD

   http://json-ld.org/

   Collection+JSON

   http://www.amundsen.com/media-types/collection/

   Siren

   https://github.com/kevinswiber/siren

   There are others as well.

   Show morethread