This document defines a new hypertext media type application/lynx+json
(a Lynx document), and a related metadata media type application/lynx-spec+json
(a Lynx specification), designed to represent and describe documents and the connections among them, with enough semantic detail to allow the development of client applications without imposing strict display constraints or unnecessary coupling between clients and servers. By reducing display constraints and coupling, developers have more freedom to create client applications that take better advantage of the unique characteristics of each platform and device.
We would like to thank the following people for their contributions to this document.
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 RFC 2119.
Refers to the media type JSON as defined in RFC 4627.
Refers to a URI as defined in RFC 3986.
Refers to a URL as defined in RFC 3986.
Refers to a URN as defined in RFC 3986.
Refers to a media type name as defined in RFC 6838.
Refers to one of the following hints: container
, link
, form
, submit
, content
, and text
.
The conveyance of a value to a user in a manner appropriate for the user agent and the user.
See Section 5.2.1.1 "Resources and Resource Identifiers" in the Fielding Dissertation.
See Section 5.2.1.2 "Representations" in the Fielding Dissertation.
An implementation is "non-compliant" if it fails to satisfy one or more of the MUST or REQUIRED level requirements. An implementation that satisfies all of the MUST or REQUIRED and all of the SHOULD level requirements is said to be "unconditionally compliant"; an implementation that satisfies all of the MUST level requirements but not all of the SHOULD level requirements is said to be "conditionally compliant."
application/lynx+json
HTTP/1.1 200 OK
Content-Type: application/lynx+json;base="http://example.com/greetings/hello-world"
{
"value": "Hello, World!",
"spec": "http://example.com/specs/greeting"
}
HTTP/1.1 200 OK
Content-Type: application/lynx+json;realm="http://example.com/entrance/greeter"
{
"value": "Hello, World!",
"spec": "http://example.com/specs/greeting"
}
application/lynx-spec+json
None
application/lynx+json
TODO: provide documentation for how the user agent interprets fragments. This may be here or it may be here or it may be in the "process for displaying content" or another section.
application/lynx-spec+json
URI fragments MUST be ignored.
The registration status of this media type is as follows:
application/lynx+json
(unregistered)application/lynx-spec+json
(unregistered).lnx
=> application/lynx+json
.lnxs
=> application/lynx-spec+json
While a JSON document may begin with an object or an array, a Lynx document MUST begin with a value/spec pair.