Page History

...

HAL reserves two properties so that clients can interpret hypermedia in a resource object: _links and _embedded. These properties are prefixed with underscores to avoid collision with properties that developers might use in actual static resource objects.

_links

This property contains one or more sub-properties. Each sub-property name defines its relation to the primary resource object. The sub-property values are themselves name/value pairs. Here is an example of a resource object containing a few link relations:

...

HAL intentionally defined link relations to be simple. To support the self-documenting and discoverability intent of a RESTful API, clients should be able to use the OPTIONS HTTP method to get a list of all supported HTTP methods for a given API. The list of all supported HTTP methods is expected to appear in the Allow response header. The SRP HTTP Framework handles this automatically.

_embedded

This property contains one or more sub-properties. Each sub-property name defines one or more embedded resource objects within the current resource object. These embedded resource objects (which are technically sub-resources) represent a partial or whole resource object that should have its own API (i.e., URI endpoint). The reason for including embedded resource objects will vary and are always based on the developer's needs. Embedded resource objects are typically added to provide one API with enough additional resource information to prevent the need for additional API calls. This is very common with collection APIs. For example, in the above resource object we identified a URI with a relation of collection. An inspection of the URI itself reveals that the endpoint is simply /customers. The absence of a unique identifier to a customer (e.g., /customers/1) is expected to mean "all customers", also referred to as "the collection of customers".

...