]> Stateless

mike@stateless.co http://stateless.co/

This document proposes a media type for representing resources and their relations as hypermedia.

There is an emergence of non-HTML HTTP applications ("Web APIs") which use hypermedia to direct clients around their resources. The JSON Hypermedia API Language (HAL) is a standard which establishes conventions for expressing hypermedia controls, such as links, with JSON . HAL is a generic media type with which Web APIs can be developed and exposed as series of links. Clients of these APIs can select links by their link relation type and traverse them in order to progress through the application. HAL's conventions result in a uniform interface for serving and consuming hypermedia, enabling the creation of general-purpose libraries that can be re-used on any API utilising HAL. The primary design goals of HAL are generality and simplicity. HAL can be applied to many different domains, and imposes the minimal amount of structure necessary to cover the key requirements of a hypermedia API.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

A HAL Document uses the format described in and has the media type "application/hal+json". Its root object MUST be a Resource Object. For example:

Here, we have a HAL document representing an order resource with the URI "/orders/523". It has "warehouse" and "invoice" links, and its own state in the form of "currency", "status", and "total" properties.

A Resource Object represents a resource. It has two reserved properties: "_links": contains links to other resources. "_embedded": contains embedded resources. All other properties MUST be valid JSON, and represent the current state of the resource.

The reserved "_links" property is OPTIONAL. It is an object whose property names are link relation types (as defined by ) and values are either a Link Object or an array of Link Objects. The subject resource of these links is the Resource Object of which the containing "_links" object is a property.

The reserved "_embedded" property is OPTIONAL It is an object whose property names are link relation types (as defined by ) and values are either a Resource Object or an array of Resource Objects.

A Link Object represents a hyperlink from the containing resource to a URI. It has the following properties:

The "href" property is REQUIRED. Its value is either a URI or a URI Template . If the value is a URI Template then the Link Object SHOULD have a "templated" attribute whose value is true.

The "templated" property is OPTIONAL. Its value is boolean and SHOULD be true when the Link Object's "href" property is a URI Template. Its value SHOULD be considered false if it is undefined or any other value than true.

The "type" property is OPTIONAL. Its value is a string used as a hint to indicate the media type expected when dereferencing the target resource.

The "name" property is OPTIONAL. Its value MAY be used as a secondary key for selecting Link Objects which share the same relation type.

The "profile" property is OPTIONAL. Its value is a string which is a URI that hints about the profile (as defined by ) of the target resource.

The "title" property is OPTIONAL. Its value is a string and is intended for labelling the link with a human-readable identifier (as defined by ).

The "hreflang" property is OPTIONAL. Its value is a string and is intended for indicating the language of the target resource (as defined by ).

The following is an example document representing a list of orders

Here, the order list document provides a "next" link directing to the next page, and a "find" link containing a URI Template which can be expanded with an 'id' variable to go directly to a specific order. It also has two embedded resources, "orders". Each of these has its own links to the associated "basket" and "customer" resources, and properties showing their "total", "currency" and "status". Additionally, the order list resource has its own properties "currentlyProcessing" and "shippedToday".

The media type identifier application/hal+json MAY also include an additional "profile" parameter (as defined by ) HAL documents that are served with the "profile" parameter still SHOULD include a "profile" link belonging to the root resource.

Each Resource Object SHOULD contain a 'self' link that corresponds with the IANA registered 'self' relation (as defined by ) whose target is the resource's URI.

Custom link relation types (Extension Relation Types in ) SHOULD be URIs that when dereferenced in a web browser provide relevant documentation, in the form of an HTML page, about the meaning and/or behaviour of the target Resource. This will improve the discoverability of the API. The CURIE Syntax MAY be used for brevity for these URIs. A CURIE is established within a HAL document via a "curie" link on the root Resource Object. This link contains a URI Template with the token 'rel', and is named via the "name" property of the Link Object.

The above demonstrates the relation "http://docs.acme.com/relations/widgets" being abbreviated to "acme:widgets" via CURIE syntax.

TBD

TBD

&rfc2119; &rfc3986; &rfc4627; &rfc5988; &rfc6570; &wilde-profile-link; &NOTE-curie;

Thanks to Darrel Miller, Mike Amundsen, and everyone in hal-discuss for their suggestions and feedback. The author takes all responsibility for errors and omissions.

There are two main approaches to solving this problem. Both involve exposing additional documentation describing the resource which may be human and/or machine readable (i.e. an HTML page and/or a JSON Schema document). The difference between the two approaches is in where that URI is shared with the client, which is either: The URI that was the preceding link relation type. A 'profile' link from the resource itself.

A list of libraries is maintained and published at the HAL Home Page

We elected for a prefix character to minimize risk of collisions with properties that represent the resource's state, and underscore was the character picked. Another reason for prefixing the reserved properties is to make it visually apparent that the reserved properties are distinct from standard properties belonging to the resource.

No, HAL only reserves the names detailed in this specification.

Omitting forms from HAL was an intentional design decision that was made to keep it focused on linking for APIs. HAL is therefore a good candidate for use as a base media type on which to build more complex capabilities. An additional media type is planned for the future which will add form-like controls on top of HAL.