idnits 2.17.1 draft-hartke-core-apps-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 12, 2016) is 2968 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 609 ** Obsolete normative reference: RFC 5785 (ref. '4') (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 5988 (ref. '5') (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 7320 (ref. '6') (Obsoleted by RFC 8820) -- Obsolete informational reference (is this intentional?): RFC 7540 (ref. '8') (Obsoleted by RFC 9113) -- Obsolete informational reference (is this intentional?): RFC 7230 (ref. '13') (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (ref. '14') (Obsoleted by RFC 9110) == Outdated reference: A later version (-02) exists of draft-li-sdnrg-design-restapi-00 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Thing-to-Thing Research Group K. Hartke 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational February 12, 2016 5 Expires: August 15, 2016 7 CoRE Application Descriptions 8 draft-hartke-core-apps-03 10 Abstract 12 The interfaces of RESTful, hypertext-driven applications consist of 13 reusable components such as Internet media types and link relation 14 types. This document defines a simple standard that application 15 designers can use to describe the interface of their application in a 16 structured way so that other parties can develop interoperable 17 clients and servers or reuse the components in their own 18 applications. 20 Note to Readers 22 This Internet-Draft should be discussed on the Thing-to-Thing 23 Research Group (T2TRG) mailing list . 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 15, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Application Descriptions . . . . . . . . . . . . . . . . . . 4 61 2.1. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Internet Media Types . . . . . . . . . . . . . . . . . . 4 63 2.2.1. Representation Formats . . . . . . . . . . . . . . . 5 64 2.2.2. Links . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.2.3. Forms . . . . . . . . . . . . . . . . . . . . . . . . 7 66 2.3. Link Relation Types . . . . . . . . . . . . . . . . . . . 8 67 2.4. Form Relation Types . . . . . . . . . . . . . . . . . . . 8 68 2.5. Well-Known Locations . . . . . . . . . . . . . . . . . . 8 69 3. Template . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4. Guidelines for Application Designers . . . . . . . . . . . . 9 71 4.1. URI Design . . . . . . . . . . . . . . . . . . . . . . . 9 72 5. Guidelines for Application Implementers . . . . . . . . . . . 10 73 5.1. Resource Navigation . . . . . . . . . . . . . . . . . . . 10 74 5.2. URI Design . . . . . . . . . . . . . . . . . . . . . . . 11 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 7.1. Content-Format Registry . . . . . . . . . . . . . . . . . 12 78 7.2. Link Relation Type Registry . . . . . . . . . . . . . . . 12 79 7.3. Form Relation Type Registry . . . . . . . . . . . . . . . 12 80 7.3.1. Registering New Form Relation Types . . . . . . . . . 12 81 7.3.2. Initial Registry Contents . . . . . . . . . . . . . . 13 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 84 8.2. Informative References . . . . . . . . . . . . . . . . . 14 85 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 Representational State Transfer (REST) [15] is an architectural style 91 for distributed hypermedia systems. Over the years, REST has gained 92 popularity not only as an approach for large-scale information 93 dissemination, but also as the basic principle for designing and 94 building Internet-based applications in general. 96 In the coming years, the size and scope of the Internet is expected 97 to greatly increase as physical-world objects become smart enough to 98 communicate over the Internet -- a phenomenon known as the Internet 99 of Things (IoT). As things learn to speak the languages of the net, 100 the idea of applying REST principles to the design of IoT application 101 architectures suggests itself. To this end, the Constrained 102 Application Protocol (CoAP) [23] has been created, an application- 103 layer protocol that enables RESTful applications in Constrained-Node 104 Networks [11], thus giving rise to a new setting for Internet-based 105 applications: the Constrained RESTful Environment (CoRE). 107 To realize the full benefits and advantages of the REST style, a set 108 of constraints needs to be maintained when designing new applications 109 and their application programming interfaces (APIs). One of the 110 fundamental principles is that "REST APIs must be hypertext-driven" 111 [16]. This principle is often ignored by application designers who 112 instead specify their APIs in terms of fixed URIs through some out- 113 of-band mechanism, e.g., in an API documentation. Although this 114 approach may appear easy for clients to use, the fixed resource names 115 and data formats lead to a tight coupling between client and server 116 implementations and make the system less flexible. Violations of 117 REST design principles like this result in APIs that may not be as 118 scalable, extensible, and interoperable as promised by REST [19]. 120 REST is intended for long-lived network-based applications that span 121 multiple organizations [16]. Principled REST APIs require some 122 design effort, as application designers do not only have to take 123 current requirements into consideration, but also have to anticipate 124 changes that may be required in the future -- years or even decades 125 after the application has been deployed for the first time. The 126 reward is long-term stability and evolvability, both of which are 127 desirable features in the Internet of Things. 129 To aid application designers in the design process, this document 130 proposes CoRE Application Descriptions, a simple standard for 131 describing the APIs of constrained, RESTful, hypertext-driven 132 applications. CoRE Application Descriptions help application 133 designers avoid common mistakes by focusing almost all of the 134 descriptive effort on defining the Internet media type(s) that are 135 used for representing resources and driving application state. 137 A template provides a consistent format for the description of APIs 138 so that implementers can easily build interoperable clients and 139 servers, and other application designers can reuse application 140 components in their own applications. 142 2. Application Descriptions 144 A CoRE Application Description is a named set of reusable components. 145 It is comprised of: 147 o URI schemes that identify communication protocols, 149 o Internet media types that identify representation formats, 151 o link relation types that identify link semantics, 153 o form relation types that identify form semantics, and 155 o optionally, well-known locations. 157 Together, these components provide the specific, in-band instructions 158 for interfacing with a given service. 160 2.1. URI Schemes 162 The foundation of a hypertext-driven REST API are the communication 163 protocol(s) spoken between a client and a server. Although HTTP/1.1 164 [13] is by far the most common communication protocol for REST APIs, 165 a REST API should typically not be dependent on any specific 166 communication protocol. 168 The use of a particular protocol is guided by URI schemes [7]. URI 169 schemes specify the syntax and semantics of URI references [1] found 170 in links (Section 2.2.2) and forms (Section 2.2.3). 172 A URI scheme refers to a family of protocols, typically distinguished 173 by a version number. For example, the "http" URI scheme refers to 174 the three members of the HTTP family of protocols: HTTP/1.0 [10], 175 HTTP/1.1 [13] and HTTP/2 [8]. The specific HTTP version is 176 negotiated between the client and the server through version 177 indicators in the protocol or the TLS application-layer protocol 178 negotiation (ALPN) extension [17]. 180 IANA maintains a list of registered URI schemes at 181 . 183 2.2. Internet Media Types 185 One of the most important aspect of hypertext-driven communications 186 is the concept of Internet media types [2]. Media types are used to 187 label representations so that it is known how the representation 188 should be interpreted and how it is encoded. The core of a CoRE 189 application description should be one or more media types. 191 A media type identifies a versioned series of representation formats 192 (Section 2.2.1): a media type does not identify a particular version 193 of a representation format; rather, the media type identifies the 194 family, and includes provisions for version indicator(s) embedded in 195 the representations themselves to determine more precisely the nature 196 of how the data is to be interpreted [20]. A new media type is only 197 needed to designate a completely incompatible format [20]. 199 Media types consist of a top-level type and a subtype, structured 200 into trees [2]. Optionally, media types can have parameters. For 201 example, the media type "text/plain; charset=utf-8" is a subtype for 202 plain text under the "text" top-level type in the standards tree and 203 has a parameter "charset" set to "utf-8". 205 Media types can be further refined by structured type name suffixes 206 (e.g., "+xml" appended to the base subtype name; see Section 4.2.8 of 207 RFC 6838), or by subtype information embedded in the representations 208 themselves (e.g., "xmlns" declarations in XML documents [12]). 209 Structured type name suffixes should be preferred, because embedded 210 subtype information cannot be negotiated (e.g., using the CoAP Accept 211 option). 213 In CoAP, media types are combined with content coding information 214 [14] to indicate the "content format" [23] of a representation. 215 Content formats are assigned a numeric identifier that can be used 216 instead of the (typically much longer) media type string in 217 representation formats with space constraints. 219 A media type must be determined from in-band information (e.g., from 220 the CoAP Content-Format option). Clients must not assume a structure 221 from the application context or other out-of-band information. 223 IANA maintains a list of registered Internet media types at 224 . 226 IANA maintains a list of registered structured suffixes at 227 . 229 IANA maintains a list of registered CoAP content formats at 230 . 232 2.2.1. Representation Formats 234 In RESTful applications, clients and servers exchange representations 235 that capture the current or intended state of a resource and that are 236 labeled with a media type. A representation is a sequence of bytes 237 whose structure and semantics are specified by a representation 238 format: a set of rules for encoding information. 240 Representation formats should generally allow clients with different 241 goals, so they can do different things with the same data. The 242 specification of a representation format "describes a problem space, 243 not a prescribed relationship between client and server. Client and 244 server must share an understanding of the representations they're 245 passing back and forth, but they don't need to have the same idea of 246 what the problem is that needs to be solved." [21] 248 Representation formats and their specifications evolve over time. It 249 is part of the responsibility of the designer of a new version of a 250 format to try to insure both forward and backward compatibility: new 251 documents should work reasonably (with some fallback) with old 252 processors, and old documents should work reasonably with new 253 processors [20]. 255 Representation formats enable hypertext-driven applications when they 256 support the expression of hypermedia controls: links (Section 2.2.2) 257 and/or forms (Section 2.2.3). 259 It is beyond the scope of this document to specify how hypermedia 260 controls can be expressed. The appropriate syntax, when available, 261 is described by the representation format specification associated 262 with each media type. 264 2.2.2. Links 266 A link is the primary means for a client to change application state, 267 i.e., to navigate from one resource to another. A link is a typed 268 connection between two resources [5], and is comprised of: 270 o a context (usually the current resource), 272 o a link relation type that identifies the semantics of the link 273 (Section 2.3), 275 o a target resource URI, and 277 o optionally, attributes that further describe the link target. 279 A link can be viewed as a statement of the form "{context} has a 280 {relation type} resource at {target URI}, which has {target 281 attributes}" [5]. For example, the resource 282 could have a "terms-of-service" resource at , 283 which has the media type "text/html". 285 There are two special kinds of links: 287 o An embedding link is a link with the additional hint that it, when 288 processed, should be substituted with a representation of the 289 referenced resource. Thus, traversing an embedding link adds to 290 the application state, rather than replacing it. 292 The most well known example for an embedding link is the HTML 293 element. When a web browser processes this element, it 294 automatically dereferences the "src" and renders the returned 295 image in place of the element. 297 o A templated link is a link where the client constructs the target 298 resource URI from provided in-band instructions. The specific 299 rules for such instructions are described by the representation 300 format. URI Templates [3] provide a generic way to construct URIs 301 through variable expansion. 303 Templated links allow a client to construct resource URIs without 304 being coupled to the resource structure at the server (provided 305 that the client learns the template from a representation sent by 306 the server and does not have the template hard coded). 308 2.2.3. Forms 310 A form is the primary means for a client to change resource state. 311 It is comprised of: 313 o a context (usually the current resource), 315 o a form relation type that identifies the semantics of the form 316 (Section 2.4), 318 o a target resource URI, 320 o a submission method (PUT, POST, PATCH, or DELETE), and 322 o a description of a representation that the service accepts as part 323 of form submission. This description can be a set of form fields 324 or simply a list of acceptable media types. 326 A form can be viewed as an instruction of the form "To {relation 327 type} the {context}, make a {method} request to {target URI}". For 328 example, to "update" the resource , a 329 client should make a PUT request to . 331 Note: A form with a submission method of GET is, strictly speaking, 332 a templated link, since it provides a way to construct a URI and 333 does not change resource state. 335 2.3. Link Relation Types 337 A link relation type identifies the semantics of a link [5]. For 338 example, a link with the relation type "copyright" indicates that the 339 resource identified by the target URI is a statement of the copyright 340 terms applying to the current context. 342 Relation types are not to be confused with media types; they do not 343 identify the format of the representation that results when the link 344 is dereferenced. Rather, they only describe how the current context 345 is related to another resource. 347 IANA maintains a list of registered link relation types at 348 . 350 Applications that don't wish to register a relation type can use an 351 extension relation type, which is a URI that uniquely identifies the 352 relation type (similar to a URI used as an XML namespace names). For 353 example, an application can use "http://example.com/foo" as link 354 relation type without having to register it. 356 In order to minimize the overhead of link relation types in 357 representation formats with space constraints, link relation types 358 are assigned a small numeric identifier that can be used in place of 359 the link relation type name (see also Section 7.2). For example, the 360 link relation type "copyright" has the numeric identifier 12. 362 2.4. Form Relation Types 364 A form relation type identifies the semantics of a form. For 365 example, a form with the relation type "create-item" indicates that a 366 new item can be created within the current context by making a 367 request to the resource identified by the target URI. 369 IANA maintains a list of registered link relation types at 370 . 372 Similar to link relation types, applications can use extension 373 relation types when they don't wish to register a relation type. 375 Form relation types are also assigned a numeric identifier that can 376 be used in place of the form relation type name. 378 2.5. Well-Known Locations 380 Some applications may require the discovery of information about a 381 host (known as "site-wide metadata" in RFC 5785 [4]). For example, 382 RFC 6415 [18] defines a metadata document format for describing 383 hosts; similarly, RFC 6690 [22] defines a link format for the 384 discovery of resources hosted by a server. 386 Applications that need to define a resource for this kind of metadata 387 can register new "well-known locations". RFC 5785 [4] defines a path 388 prefix in "http" and "https" URIs for this purpose, "/.well-known/"; 389 RFC 7252 [23] extends this concept to "coap" and "coaps" URIs. 391 IANA maintains a list of registered well-known URIs at 392 . 394 3. Template 396 Application name: 398 URI schemes: 400 Media types: 402 Link relation types: 404 Form relation types: 406 Well-known locations: 408 Interoperability considerations: 410 Security considerations: 412 Contact: 414 Author/Change controller: 416 4. Guidelines for Application Designers 418 This section provides guidelines and recommendations for designers of 419 constrained, RESTful, hypertext-driven applications. 421 4.1. URI Design 423 URIs [1] are a cornerstone of RESTful applications. They enable 424 uniform identification of resources via URI schemes [7] and are used 425 every time a client interacts with a particular resource or when a 426 resource representation references another resource. 428 URIs often include structured application data in the path and query 429 components, such as paths in a filesystem or keys in a database. It 430 is common for many REST APIs to prescribe a fixed format for this 431 data. However, there are a number of problems with this practice 432 [6], in particular if the application designer and the server owner 433 are not the same entity. 435 Therefore, in hypertext-driven applications URIs are not included in 436 the application interface. A CoRE Application Description must not 437 mandate any particular form of URI substructure that is not 438 explicitly allowed by RFC 3986 [1]. 440 RFC 7320 [6] describes the problematic practice of fixed URI 441 structures in detail and provides some acceptable alternatives. 442 Section 5.2 gives some recommendations on URI design for application 443 implementers. 445 5. Guidelines for Application Implementers 447 This section provides guidelines and recommendations for implementers 448 of application descriptions, on both the client and the server side. 450 5.1. Resource Navigation 452 Links (Section 2.2.2) and forms (Section 2.2.3) afford a potential 453 next or future request from the client to a server. To make the 454 request, the client needs to select a link or a form from a set of 455 candidates. The process is as follows: 457 1. The first step for a client is to decide what to do next, i.e., 458 which link to follow or which form to submit, based on the link 459 relation types (Section 2.3) and form relation types 460 (Section 2.4) it understands. 462 2. The client finds the link(s) or form(s) with the given relation 463 type. This may yield one or more candidates from which the 464 client must select the most appropriate one. The set of 465 candidates may be empty if the transition is not allowed, for 466 example, when the client is unauthorized. 468 3. The client selects one of the candidates based on the metadata 469 associated with the hypermedia control. This includes the media 470 type of the target resource representation, the URI scheme, the 471 request method, and other attributes that describe the link 472 target. 474 4. The client resolves the target resource URI reference to its 475 absolute form in order to obtain the "request URI". The process 476 for reference resolution is specified in Section 5 of RFC 3986 477 [1]. 479 5. The client constructs the request. The request URI is the target 480 resource URI resolved in the previous step. The request method 481 is either GET for links or indicated by the hypermedia control 482 for forms. The client should set request metadata according to 483 the link/form attributes (e.g., set the CoAP Accept option when 484 the media type of the target resource is specified). In case of 485 a form, the client also constructs a request payload according to 486 the instructions specified in the form. 488 6. Finally, the client sends the request and retrieves the response. 489 The application thereby transitions to a new state and the client 490 can decide again what to do next. 492 5.2. URI Design 494 Even though URIs are not part of the application interface (see 495 Section 4.1), the design of the URI structure on a server is an 496 essential part of implementing a RESTful application. The server 497 implementer is responsible for binding the nouns identified by the 498 application designer to URIs. 500 A good RESTful URI is: 502 o Short. Short URIs are easier to remember and cause less overhead 503 in requests and representations. 505 o Meaningful. A URI should describe the resource in a way that is 506 meaningful and useful to humans. 508 o Consistent. URIs should follow a consistent pattern to make it 509 easy to reason about the application. 511 o Bookmarkable. Cool URIs don't change [9]. However, application 512 resource structures change. That should naturally cause URIs to 513 change so they better reflect reality. So implementations should 514 not depend on unchanging URIs. 516 o Shareable. A URI should not be context sensitive, e.g., to the 517 currently logged-in user. It should be possible to share a URI 518 with third parties so they can access the same resource. 520 o Extension-less. Some applications return different data for 521 different extensions, e.g., for "contacts.xml" or "contacts.json". 522 But different URIs imply different resources. RESTful URIs should 523 identify a single resource. Different representations of the 524 resource can be negotiated (e.g., using the CoAP Accept option). 526 6. Security Considerations 528 The security considerations of RFC 3986 [1], RFC 5785 [4], RFC 5988 529 [5], RFC 6570 [3], RFC 6838 [2], RFC 7320 [6], and RFC 7595 [7] are 530 inherited. 532 All components of an application description are expected to contain 533 clear security considerations. CoRE Application Descriptions should 534 furthermore contain security considerations that need to be taken 535 into account for the security of the overall application. 537 7. IANA Considerations 539 [Note to RFC Editor: Please replace XXXX in this section with the RFC 540 number of this specification.] 542 7.1. Content-Format Registry 544 RFC 6838 [2] establishes a IANA registry for media types. Many of 545 these media types are also useful in constrained environments as CoAP 546 content formats. RFC 7252 [23] establishes a IANA registry for these 547 content formats. This specification tasks IANA with the allocation 548 of a content format for any existing or new media type registration 549 that does not define any parameters (required or optional). The 550 content formats shall be allocated in the range 1000-9999. 552 7.2. Link Relation Type Registry 554 RFC 5988 [5] establishes a IANA registry for link relation types. 555 This specification extends the registration template with a "Relation 556 ID": a numeric identifier that can be used instead of the "Relation 557 Name" to identify a link relation type. IANA is tasked with the 558 assignment of an ID to any existing or new link relation type. The 559 IDs shall be assigned in the range 1-9999. 561 7.3. Form Relation Type Registry 563 This specification establishes a IANA registry for form relation 564 types. 566 7.3.1. Registering New Form Relation Types 568 Form relation types are registered in the same way as link relation 569 types [5], i.e., they are registered on the advice of a Designated 570 Expert with a Specification Required. 572 The requirements for registered relation types are adopted from 573 Section 4.1 of RFC 5988 [5]. 575 The registration template is: 577 o Relation Name: 579 o Relation ID: 581 o Description: 583 o Reference: 585 o Notes: [optional] 587 The IDs shall be assigned in the range 1-9999. 589 7.3.2. Initial Registry Contents 591 The Form Relation Type registry's initial contents are: 593 o Relation Name: create-item 594 Relation ID: 1 595 Description: Refers to a resource that can be used to create a 596 resource in a collection of resources. 597 Reference: [RFCXXXX] 599 o Relation Name: delete 600 Relation ID: 2 601 Description: Refers to a resource that can be used to delete a 602 resource in a collection of resources. 603 Reference: [RFCXXXX] 605 o Relation Name: update 606 Relation ID: 3 607 Description: Refers to a resource that can be used to update the 608 state of the form's context. 609 Reference: [RFCXXXX] 611 8. References 613 8.1. Normative References 615 [1] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 616 Resource Identifier (URI): Generic Syntax", STD 66, 617 RFC 3986, DOI 10.17487/RFC3986, January 2005, 618 . 620 [2] Freed, N., Klensin, J., and T. Hansen, "Media Type 621 Specifications and Registration Procedures", BCP 13, 622 RFC 6838, DOI 10.17487/RFC6838, January 2013, 623 . 625 [3] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 626 and D. Orchard, "URI Template", RFC 6570, 627 DOI 10.17487/RFC6570, March 2012, 628 . 630 [4] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 631 Uniform Resource Identifiers (URIs)", RFC 5785, 632 DOI 10.17487/RFC5785, April 2010, 633 . 635 [5] Nottingham, M., "Web Linking", RFC 5988, 636 DOI 10.17487/RFC5988, October 2010, 637 . 639 [6] Nottingham, M., "URI Design and Ownership", BCP 190, 640 RFC 7320, DOI 10.17487/RFC7320, July 2014, 641 . 643 [7] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 644 and Registration Procedures for URI Schemes", BCP 35, 645 RFC 7595, DOI 10.17487/RFC7595, June 2015, 646 . 648 8.2. Informative References 650 [8] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 651 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 652 DOI 10.17487/RFC7540, May 2015, 653 . 655 [9] Berners-Lee, T., "Cool URIs don't change", 1998, 656 . 658 [10] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 659 Transfer Protocol -- HTTP/1.0", RFC 1945, 660 DOI 10.17487/RFC1945, May 1996, 661 . 663 [11] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 664 Constrained-Node Networks", RFC 7228, 665 DOI 10.17487/RFC7228, May 2014, 666 . 668 [12] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. 669 Thompson, "Namespaces in XML 1.0 (Third Edition)", World 670 Wide Web Consortium Recommendation REC-xml-names-20091208, 671 December 2009, 672 . 674 [13] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 675 Protocol (HTTP/1.1): Message Syntax and Routing", 676 RFC 7230, DOI 10.17487/RFC7230, June 2014, 677 . 679 [14] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 680 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 681 DOI 10.17487/RFC7231, June 2014, 682 . 684 [15] Fielding, R., "Architectural Styles and the Design of 685 Network-based Software Architectures", Ph.D. Dissertation, 686 University of California, Irvine, 2000, 687 . 690 [16] Fielding, R., "REST APIs must be hypertext-driven", 691 October 2008, . 694 [17] Friedl, S., Popov, A., Langley, A., and E. Stephan, 695 "Transport Layer Security (TLS) Application-Layer Protocol 696 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 697 July 2014, . 699 [18] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata", 700 RFC 6415, DOI 10.17487/RFC6415, October 2011, 701 . 703 [19] Li, L., Wei, Z., Luo, M., and W. Chou, "Requirements and 704 Design Patterns for REST Northbound API in SDN", draft-li- 705 sdnrg-design-restapi-00 (work in progress), March 2015. 707 [20] Masinter, L., "MIME and the Web", draft-masinter-mime-web- 708 info-02 (work in progress), January 2011. 710 [21] Richardson, L. and M. Amundsen, "RESTful Web APIs", 711 O'Reilly Media, ISBN 978-1-4493-5806-8, September 2013. 713 [22] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 714 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 715 . 717 [23] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 718 Application Protocol (CoAP)", RFC 7252, 719 DOI 10.17487/RFC7252, June 2014, 720 . 722 Acknowledgements 724 Thanks to Jan Algermissen, Mike Amundsen, Olaf Bergmann, Carsten 725 Bormann, Stefanie Gerdes, Mike Kelly, Ari Keranen, Michael Koster, 726 Matthias Kovatsch, Julian Reschke, Teemu Savolainen, Bilhanan 727 Silverajan, and Erik Wilde for helpful comments and discussions that 728 have shaped the document. 730 Some of the text in this document has been borrowed from [5], [6], 731 [16], [19], and [20]. All errors are my own. 733 This work was funded in part by Nokia. 735 Author's Address 737 Klaus Hartke 738 Universitaet Bremen TZI 739 Postfach 330440 740 Bremen D-28359 741 Germany 743 Phone: +49-421-218-63905 744 Email: hartke@tzi.org