CoRE Application Descriptions
draft-hartke-core-apps-05
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Klaus Hartke | ||
| Last updated | 2016-10-29 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hartke-core-apps-05
Thing-to-Thing Research Group K. Hartke
Internet-Draft Universitaet Bremen TZI
Intended status: Informational October 29, 2016
Expires: May 2, 2017
CoRE Application Descriptions
draft-hartke-core-apps-05
Abstract
The interfaces of RESTful, hypertext-driven applications consist of
reusable components such as Internet media types and link relation
types. This document defines a simple standard that application
designers can use to describe the interface of their application in a
structured way so that other parties can develop interoperable
clients and servers or reuse the components in their own
applications.
Note to Readers
This Internet-Draft should be discussed on the Thing-to-Thing
Research Group (T2TRG) mailing list <t2trg@irtf.org>
<https://www.irtf.org/mailman/listinfo/t2trg>.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 2, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
Hartke Expires May 2, 2017 [Page 1]
Internet-Draft CoRE Application Descriptions October 2016
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Application Descriptions . . . . . . . . . . . . . . . . . . 4
2.1. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Internet Media Types . . . . . . . . . . . . . . . . . . 4
2.2.1. Representation Formats . . . . . . . . . . . . . . . 6
2.2.2. Links . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.3. Forms . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Link Relation Types . . . . . . . . . . . . . . . . . . . 8
2.4. Form Relation Types . . . . . . . . . . . . . . . . . . . 8
2.5. Form Field Names . . . . . . . . . . . . . . . . . . . . 9
2.6. Well-Known Locations . . . . . . . . . . . . . . . . . . 9
3. Template . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. URI Design Considerations . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. Content-Format Registry . . . . . . . . . . . . . . . . . 12
6.2. Link Relation Type Registry . . . . . . . . . . . . . . . 12
6.3. Form Relation Type Registry . . . . . . . . . . . . . . . 12
6.3.1. Registering New Form Relation Types . . . . . . . . . 12
6.3.2. Initial Registry Contents . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
Representational State Transfer (REST) [15] is an architectural style
for distributed hypermedia systems. Over the years, REST has gained
popularity not only as an approach for large-scale information
dissemination, but also as the basic principle for designing and
building Internet-based applications in general.
In the coming years, the size and scope of the Internet is expected
to greatly increase as physical-world objects become smart enough to
Hartke Expires May 2, 2017 [Page 2]
Internet-Draft CoRE Application Descriptions October 2016
communicate over the Internet -- a phenomenon known as the Internet
of Things (IoT). As things learn to speak the languages of the net,
the idea of applying REST principles to the design of IoT application
architectures suggests itself. To this end, the Constrained
Application Protocol (CoAP) [23] has been created, an application-
layer protocol that enables RESTful applications in Constrained-Node
Networks [11], thus giving rise to a new setting for Internet-based
applications: the Constrained RESTful Environment (CoRE).
To realize the full benefits and advantages of the REST style, a set
of constraints needs to be maintained when designing new applications
and their application programming interfaces (APIs). One of the
fundamental principles is that "REST APIs must be hypertext-driven"
[16]. This principle is often ignored by application designers who
instead specify their APIs in terms of fixed URIs through some out-
of-band mechanism, e.g., in an API documentation. Although this
approach may appear easy for clients to use, the fixed resource names
and data formats lead to a tight coupling between client and server
implementations and make the system less flexible. Violations of
REST design principles like this result in APIs that may not be as
scalable, extensible, and interoperable as promised by REST [19].
REST is intended for long-lived network-based applications that span
multiple organizations [16]. Principled REST APIs require some
design effort, as application designers do not only have to take
current requirements into consideration, but also have to anticipate
changes that may be required in the future -- years or even decades
after the application has been deployed for the first time. The
reward is long-term stability and evolvability, both of which are
desirable features in the Internet of Things.
To aid application designers in the design process, this document
proposes CoRE Application Descriptions, a simple standard for
describing the APIs of constrained, RESTful, hypertext-driven
applications. CoRE Application Descriptions help application
designers avoid common mistakes by focusing almost all of the
descriptive effort on defining the Internet media type(s) that are
used for representing resources and driving application state.
A template provides a consistent format for the description of APIs
so that implementers can easily build interoperable clients and
servers, and other application designers can reuse application
components in their own applications.
Hartke Expires May 2, 2017 [Page 3]
Internet-Draft CoRE Application Descriptions October 2016
2. Application Descriptions
A CoRE Application Description is a named set of reusable components.
It is comprised of:
o URI schemes that identify communication protocols,
o Internet media types that identify representation formats,
o link relation types that identify link semantics,
o form relation types that identify form semantics,
o form field names that identify form field semantics, and
o optionally, well-known locations.
Together, these components provide the specific, in-band instructions
for interfacing with a given service.
2.1. URI Schemes
The foundation of a hypertext-driven REST API are the communication
protocol(s) spoken between a client and a server. Although HTTP/1.1
[13] is by far the most common communication protocol for REST APIs,
a REST API should typically not be dependent on any specific
communication protocol.
The use of a particular protocol is guided by URI schemes [7]. A URI
scheme refers to a family of protocols, typically distinguished by a
version number. For example, the "http" URI scheme refers to the
three members of the HTTP family of protocols: HTTP/1.0 [10],
HTTP/1.1 [13], and HTTP/2 [8]. The specific HTTP version is
negotiated between the client and the server through version
indicators in the protocol or the TLS application-layer protocol
negotiation (ALPN) extension [17].
URI schemes also specify the syntax and semantics of URI references
[1] found in links (Section 2.2.2) and forms (Section 2.2.3).
IANA maintains a list of registered URI schemes at
<http://www.iana.org/assignments/uri-schemes>.
2.2. Internet Media Types
One of the most important aspect of hypertext-driven communications
is the concept of Internet media types [2]. Media types are used to
label representations so that it is known how the representation
Hartke Expires May 2, 2017 [Page 4]
Internet-Draft CoRE Application Descriptions October 2016
should be interpreted and how it is encoded. The core of a CoRE
application description should be one or more media types.
A media type identifies a versioned series of representation formats
(Section 2.2.1): a media type does not identify a particular version
of a representation format; rather, the media type identifies the
family, and includes provisions for version indicator(s) embedded in
the representations themselves to determine more precisely the nature
of how the data is to be interpreted [20]. A new media type is only
needed to designate a completely incompatible format [20].
Media types consist of a top-level type and a subtype, structured
into trees [2]. Optionally, media types can have parameters. For
example, the media type "text/plain; charset=utf-8" is a subtype for
plain text under the "text" top-level type in the standards tree and
has a parameter "charset" set to "utf-8".
Media types can be further refined by structured type name suffixes
(e.g., "+xml" appended to the base subtype name; see Section 4.2.8 of
RFC 6838), or by subtype information embedded in the representations
themselves (e.g., "xmlns" declarations in XML documents [12]).
Structured type name suffixes should generally be preferred, because
embedded subtype information can typically not be negotiated (e.g.,
using the CoAP Accept option).
In CoAP, media types are combined with content coding information
[14] to indicate the "content format" [23] of a representation.
Content formats are assigned a numeric identifier that can be used
instead of the (typically much longer) textual name of the media type
in representation formats with space constraints. However, a flat
number space as in CoAP loses the structural information of textual
names.
A media type must be determined from in-band information (e.g., from
the CoAP Content-Format option). Clients must not assume a structure
from the application context or other out-of-band information.
IANA maintains a list of registered Internet media types at
<http://www.iana.org/assignments/media-types>.
IANA maintains a list of registered structured suffixes at
<http://www.iana.org/assignments/media-type-structured-suffix>.
IANA maintains a list of registered CoAP content formats at
<http://www.iana.org/assignments/core-parameters>.
Hartke Expires May 2, 2017 [Page 5]
Internet-Draft CoRE Application Descriptions October 2016
2.2.1. Representation Formats
In RESTful applications, clients and servers exchange representations
that capture the current or intended state of a resource and that are
labeled with a media type. A representation is a sequence of bytes
whose structure and semantics are specified by a representation
format: a set of rules for encoding information.
Representation formats should generally allow clients with different
goals, so they can do different things with the same data. The
specification of a representation format "describes a problem space,
not a prescribed relationship between client and server. Client and
server must share an understanding of the representations they're
passing back and forth, but they don't need to have the same idea of
what the problem is that needs to be solved." [21]
Representation formats and their specifications evolve over time. It
is part of the responsibility of the designer of a new version of a
format to try to insure both forward and backward compatibility: new
documents should work reasonably (with some fallback) with old
processors, and old documents should work reasonably with new
processors [20].
Representation formats enable hypertext-driven applications when they
support the expression of hypermedia controls: links (Section 2.2.2)
and/or forms (Section 2.2.3).
2.2.2. Links
A link is a typed connection between two resources [5] and the
primary means for a client to navigate from one resource to another.
It is comprised of:
o a link context (usually the current resource),
o a link relation type that identifies the semantics of the link
(see Section 2.3),
o a link target, and
o optionally, target attributes that further describe the link or
its target.
A link can be viewed as a statement of the form "{link context} has a
{link relation type} resource at {link target}, which has {target
attributes}" [5]. For example, the resource <http://example.com/>
could have a "terms-of-service" resource at <http://example.com/tos>,
which has the media type "text/html".
Hartke Expires May 2, 2017 [Page 6]
Internet-Draft CoRE Application Descriptions October 2016
There are two special kinds of links:
o An embedding link is a link with the additional hint that it, when
processed, should be substituted with a representation of the
referenced resource. Thus, traversing an embedding link adds to
the current state, rather than replacing it.
The most well known example for an embedding link is the HTML
<img> element. When a web browser processes this element, it
automatically dereferences the "src" and renders the returned
image in place of the <img> element.
o A templated link is a link where the client constructs the target
resource URI from provided in-band instructions. The specific
rules for such instructions are described by the representation
format. URI Templates [3] provide a generic way to construct URIs
through variable expansion.
Templated links allow a client to construct resource URIs without
being coupled to the resource structure at the server (provided
that the client learns the template from a representation sent by
the server and does not have the template hard coded).
2.2.3. Forms
A form is the primary means for a client to submit information to a
server, typically in order to change resource state. It is comprised
of:
o a form context (usually the current resource),
o a form relation type that identifies the semantics of the form
(see Section 2.4),
o a form target,
o a submission method (PUT, POST, PATCH, FETCH, or DELETE),
o a description of a representation that the service expects as part
of form submission, and
o optionally, target attributes that further describe the form or
its target.
A form can be viewed as an instruction of the form "To {form relation
type} the {form context}, make a {method} request to {form target}".
For example, to "update" the resource <http://example.com/config>, a
client should make a PUT request to <http://example.com/config>.
Hartke Expires May 2, 2017 [Page 7]
Internet-Draft CoRE Application Descriptions October 2016
The description of the expected representation can be a set of form
fields (see Section 2.5) or simply a list of acceptable media types.
Note: A form with a submission method of GET is, strictly speaking,
a templated link, since it provides a way to construct a URI and
does not change resource state.
2.3. Link Relation Types
A link relation type identifies the semantics of a link [5]. For
example, a link with the relation type "copyright" indicates that the
resource identified by the target URI is a statement of the copyright
terms applying to the link context.
Relation types are not to be confused with media types; they do not
identify the format of the representation that results when the link
is dereferenced. Rather, they only describe how the link context is
related to another resource.
IANA maintains a list of registered link relation types at
<http://www.iana.org/assignments/link-relations>.
Applications that don't wish to register a link relation type can use
an extension link relation type, which is a URI that uniquely
identifies the link relation type (similar to a URI used as an XML
namespace name). For example, an application can use the string
"http://example.com/foo" as link relation type without having to
register it. Using a URI to identify an extension link relation
type, rather than a simple string, reduces the probability of
different link relation types using the same identifiers.
In order to minimize the overhead of link relation types in
representation formats with space constraints, IANA-registered link
relation types are assigned a numeric identifier that can be used in
place of the textual name (see also Section 6.2). For example, the
link relation type "copyright" has the numeric identifier 12.
Representation formats may provide numeric identifiers for extension
link relation types.
2.4. Form Relation Types
A form relation type identifies the semantics of a form. For
example, a form with the form relation type "create-item" indicates
that a new item can be created within the form context by making a
request to the resource identified by the target URI.
IANA maintains a list of registered form relation types at
<TBD>.
Hartke Expires May 2, 2017 [Page 8]
Internet-Draft CoRE Application Descriptions October 2016
Similar to link relation types, applications can use extension form
relation types when they don't wish to register a form relation type.
IANA-registered form relation types are assigned a numeric identifier
that can be used in place of the textual name. For example, the
"create-item" form relation type has the numeric identifier 1.
Representation formats may provide numeric identifiers for extension
form relation types.
2.5. Form Field Names
Forms can have a detailed description of the representation expected
by the server as part of form submission. This description typically
consists of a set of form fields where each form field is comprised
of a field name, a field type, and optionally a number of attributes
such as a default value, a validation rule or a human-readable label.
To enable an automated client to fill out a form, the field name can
be used to identify the semantics of the form field. For example,
when controlling a smart light bulb, the field name "brightness"
could indicate the field for setting the desired brightness of the
light bulb. Field names are scoped to form relation types, i.e., two
form fields with the same name can have different semantics if they
appear in forms with different form relation types.
The type of a form field is a data type such as "an integer between 1
and 100" or "a RGB color". The type is orthogonal to the field name,
i.e., the type should not be determined from the field name even
though the client can identify the semantics of the field from the
name. This separation makes it easy to expand the set of acceptable
values in the future.
2.6. Well-Known Locations
Some applications may require the discovery of information about a
host (known as "site-wide metadata" in RFC 5785 [4]). For example,
RFC 6415 [18] defines a metadata document format for describing a
host; similarly, RFC 6690 [22] defines a link format for the
discovery of resources hosted by a server.
Applications that need to define a resource for this kind of metadata
can register new "well-known locations". RFC 5785 [4] defines a path
prefix in "http" and "https" URIs for this purpose, "/.well-known/";
RFC 7252 [23] extends this convention to "coap" and "coaps" URIs.
IANA maintains a list of registered well-known URIs at
<http://www.iana.org/assignments/well-known-uris>.
Hartke Expires May 2, 2017 [Page 9]
Internet-Draft CoRE Application Descriptions October 2016
3. Template
Application name:
URI schemes:
Media types:
Link relation types:
Form relation types:
Form field names:
Well-known locations:
Interoperability considerations:
Security considerations:
Contact:
Author/Change controller:
4. URI Design Considerations
URIs [1] are a cornerstone of RESTful applications. They enable
uniform identification of resources via URI schemes [7] and are used
every time a client interacts with a particular resource or when a
resource representation references another resource.
URIs often include structured application data in the path and query
components, such as paths in a filesystem or keys in a database. It
is common for many RESTful applications to use these structures not
only as an implementation detail but also make them part of the
public REST API, prescribing a fixed format for this data. However,
there are a number of problems with this practice [6], in particular
if the application designer and the server owner are not the same
entity.
In hypertext-driven applications URIs are therefore not included in
the application interface. A CoRE Application Description must not
mandate any particular form of URI substructure.
RFC 7320 [6] describes the problematic practice of fixed URI
structures in detail and provides some acceptable alternatives.
Hartke Expires May 2, 2017 [Page 10]
Internet-Draft CoRE Application Descriptions October 2016
That said, the design of the URI structure on a server is an
essential part of implementing a RESTful application, even though it
is not part of the application interface. The server implementer is
responsible for binding the resources identified by the application
designer to URIs.
A good RESTful URI is:
o Short. Short URIs are easier to remember and cause less overhead
in requests and representations.
o Meaningful. A URI should describe the resource in a way that is
meaningful and useful to humans.
o Consistent. URIs should follow a consistent pattern to make it
easy to reason about the application.
o Bookmarkable. Cool URIs don't change [9]. However, application
resource structures change. That should naturally cause URIs to
change so they better reflect reality. So implementations should
not depend on unchanging URIs.
o Shareable. A URI should not be context sensitive, e.g., to the
currently logged-in user. It should be possible to share a URI
with third parties so they can access the same resource.
o Extension-less. Some applications return different data for
different extensions, e.g., for "contacts.xml" or "contacts.json".
But different URIs imply different resources. RESTful URIs should
identify a single resource. Different representations of the
resource can be negotiated (e.g., using the CoAP Accept option).
5. Security Considerations
The security considerations of RFC 3986 [1], RFC 5785 [4], RFC 5988
[5], RFC 6570 [3], RFC 6838 [2], RFC 7320 [6], and RFC 7595 [7] are
inherited.
All components of an application description are expected to contain
clear security considerations. CoRE Application Descriptions should
furthermore contain security considerations that need to be taken
into account for the security of the overall application.
6. IANA Considerations
[Note to RFC Editor: Please replace XXXX in this section with the RFC
number of this specification.]
Hartke Expires May 2, 2017 [Page 11]
Internet-Draft CoRE Application Descriptions October 2016
6.1. Content-Format Registry
RFC 6838 [2] establishes a IANA registry for media types. Many of
these media types are also useful in constrained environments as CoAP
content formats. RFC 7252 [23] establishes a IANA registry for these
content formats. This specification tasks IANA with the allocation
of a content format for any existing or new media type registration
that does not define any parameters (required or optional). The
content formats shall be allocated in the range 1000-9999.
6.2. Link Relation Type Registry
RFC 5988 [5] establishes a IANA registry for link relation types.
This specification extends the registration template with a "Relation
ID": a numeric identifier that can be used instead of the "Relation
Name" to identify a link relation type. IANA is tasked with the
assignment of an ID to any existing or new link relation type. The
IDs shall be assigned in the range 1-9999.
6.3. Form Relation Type Registry
This specification establishes a IANA registry for form relation
types.
6.3.1. Registering New Form Relation Types
Form relation types are registered in the same way as link relation
types [5], i.e., they are registered on the advice of a Designated
Expert with a Specification Required.
The requirements for registered relation types are adopted from
Section 4.1 of RFC 5988 [5].
The registration template is:
o Relation Name:
o Relation ID:
o Description:
o Reference:
o Notes: [optional]
The IDs shall be assigned in the range 1-9999.
Hartke Expires May 2, 2017 [Page 12]
Internet-Draft CoRE Application Descriptions October 2016
6.3.2. Initial Registry Contents
The Form Relation Type registry's initial contents are:
o Relation Name: create-item
Relation ID: 1
Description: Refers to a resource that can be used to create a
resource in a collection of resources.
Reference: [RFCXXXX]
o Relation Name: delete
Relation ID: 2
Description: Refers to a resource that can be used to delete a
resource in a collection of resources.
Reference: [RFCXXXX]
o Relation Name: update
Relation ID: 3
Description: Refers to a resource that can be used to update the
state of the form context.
Reference: [RFCXXXX]
o Relation Name: search
Relation ID: 4
Description: Refers to a resource that can be used to search the
form context.
Reference: [RFCXXXX]
7. References
7.1. Normative References
[1] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[2] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<http://www.rfc-editor.org/info/rfc6838>.
[3] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570,
DOI 10.17487/RFC6570, March 2012,
<http://www.rfc-editor.org/info/rfc6570>.
Hartke Expires May 2, 2017 [Page 13]
Internet-Draft CoRE Application Descriptions October 2016
[4] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010,
<http://www.rfc-editor.org/info/rfc5785>.
[5] Nottingham, M., "Web Linking", RFC 5988,
DOI 10.17487/RFC5988, October 2010,
<http://www.rfc-editor.org/info/rfc5988>.
[6] Nottingham, M., "URI Design and Ownership", BCP 190,
RFC 7320, DOI 10.17487/RFC7320, July 2014,
<http://www.rfc-editor.org/info/rfc7320>.
[7] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
and Registration Procedures for URI Schemes", BCP 35,
RFC 7595, DOI 10.17487/RFC7595, June 2015,
<http://www.rfc-editor.org/info/rfc7595>.
7.2. Informative References
[8] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<http://www.rfc-editor.org/info/rfc7540>.
[9] Berners-Lee, T., "Cool URIs don't change", 1998,
<http://www.w3.org/Provider/Style/URI.html>.
[10] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945,
DOI 10.17487/RFC1945, May 1996,
<http://www.rfc-editor.org/info/rfc1945>.
[11] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
[12] Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
Thompson, "Namespaces in XML 1.0 (Third Edition)", World
Wide Web Consortium Recommendation REC-xml-names-20091208,
December 2009,
<http://www.w3.org/TR/2009/REC-xml-names-20091208>.
[13] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
Hartke Expires May 2, 2017 [Page 14]
Internet-Draft CoRE Application Descriptions October 2016
[14] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>.
[15] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", Ph.D. Dissertation,
University of California, Irvine, 2000,
<http://www.ics.uci.edu/~fielding/pubs/dissertation/
fielding_dissertation.pdf>.
[16] Fielding, R., "REST APIs must be hypertext-driven",
October 2008, <http://roy.gbiv.com/untangled/2008/
rest-apis-must-be-hypertext-driven>.
[17] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <http://www.rfc-editor.org/info/rfc7301>.
[18] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata",
RFC 6415, DOI 10.17487/RFC6415, October 2011,
<http://www.rfc-editor.org/info/rfc6415>.
[19] Li, L., Wei, Z., Luo, M., and W. Chou, "Requirements and
Design Patterns for REST Northbound API in SDN", draft-li-
sdnrg-design-restapi-02 (work in progress), July 2016.
[20] Masinter, L., "MIME and the Web", draft-masinter-mime-web-
info-02 (work in progress), January 2011.
[21] Richardson, L. and M. Amundsen, "RESTful Web APIs",
O'Reilly Media, ISBN 978-1-4493-5806-8, September 2013.
[22] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<http://www.rfc-editor.org/info/rfc6690>.
[23] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
Acknowledgements
Jan Algermissen, Mike Amundsen, Mike Kelly, Julian Reschke, and Erik
Wilde provided valuable input on link and form relation types.
Hartke Expires May 2, 2017 [Page 15]
Internet-Draft CoRE Application Descriptions October 2016
Thanks to Olaf Bergmann, Carsten Bormann, Stefanie Gerdes, Ari
Keranen, Michael Koster, Matthias Kovatsch, Teemu Savolainen, and
Bilhanan Silverajan for helpful comments and discussions that have
shaped the document.
Some of the text in this document has been borrowed from [5], [6],
[16], [19], and [20]. All errors are my own.
This work was funded in part by Nokia.
Author's Address
Klaus Hartke
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63905
Email: hartke@tzi.org
Hartke Expires May 2, 2017 [Page 16]