idnits 2.17.1 draft-hartke-core-apps-04.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 (October 10, 2016) is 2753 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 551 ** 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) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 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 October 10, 2016 5 Expires: April 13, 2017 7 CoRE Application Descriptions 8 draft-hartke-core-apps-04 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 24 . 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 13, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Application Descriptions . . . . . . . . . . . . . . . . . . 4 62 2.1. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Internet Media Types . . . . . . . . . . . . . . . . . . 4 64 2.2.1. Representation Formats . . . . . . . . . . . . . . . 5 65 2.2.2. Links . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.2.3. Forms . . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.3. Link Relation Types . . . . . . . . . . . . . . . . . . . 8 68 2.4. Form Relation Types . . . . . . . . . . . . . . . . . . . 8 69 2.5. Well-Known Locations . . . . . . . . . . . . . . . . . . 9 70 3. Template . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4. URI Design Considerations . . . . . . . . . . . . . . . . . . 9 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 6.1. Content-Format Registry . . . . . . . . . . . . . . . . . 11 75 6.2. Link Relation Type Registry . . . . . . . . . . . . . . . 11 76 6.3. Form Relation Type Registry . . . . . . . . . . . . . . . 11 77 6.3.1. Registering New Form Relation Types . . . . . . . . . 11 78 6.3.2. Initial Registry Contents . . . . . . . . . . . . . . 12 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 81 7.2. Informative References . . . . . . . . . . . . . . . . . 13 82 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 Representational State Transfer (REST) [15] is an architectural style 88 for distributed hypermedia systems. Over the years, REST has gained 89 popularity not only as an approach for large-scale information 90 dissemination, but also as the basic principle for designing and 91 building Internet-based applications in general. 93 In the coming years, the size and scope of the Internet is expected 94 to greatly increase as physical-world objects become smart enough to 95 communicate over the Internet -- a phenomenon known as the Internet 96 of Things (IoT). As things learn to speak the languages of the net, 97 the idea of applying REST principles to the design of IoT application 98 architectures suggests itself. To this end, the Constrained 99 Application Protocol (CoAP) [23] has been created, an application- 100 layer protocol that enables RESTful applications in Constrained-Node 101 Networks [11], thus giving rise to a new setting for Internet-based 102 applications: the Constrained RESTful Environment (CoRE). 104 To realize the full benefits and advantages of the REST style, a set 105 of constraints needs to be maintained when designing new applications 106 and their application programming interfaces (APIs). One of the 107 fundamental principles is that "REST APIs must be hypertext-driven" 108 [16]. This principle is often ignored by application designers who 109 instead specify their APIs in terms of fixed URIs through some out- 110 of-band mechanism, e.g., in an API documentation. Although this 111 approach may appear easy for clients to use, the fixed resource names 112 and data formats lead to a tight coupling between client and server 113 implementations and make the system less flexible. Violations of 114 REST design principles like this result in APIs that may not be as 115 scalable, extensible, and interoperable as promised by REST [19]. 117 REST is intended for long-lived network-based applications that span 118 multiple organizations [16]. Principled REST APIs require some 119 design effort, as application designers do not only have to take 120 current requirements into consideration, but also have to anticipate 121 changes that may be required in the future -- years or even decades 122 after the application has been deployed for the first time. The 123 reward is long-term stability and evolvability, both of which are 124 desirable features in the Internet of Things. 126 To aid application designers in the design process, this document 127 proposes CoRE Application Descriptions, a simple standard for 128 describing the APIs of constrained, RESTful, hypertext-driven 129 applications. CoRE Application Descriptions help application 130 designers avoid common mistakes by focusing almost all of the 131 descriptive effort on defining the Internet media type(s) that are 132 used for representing resources and driving application state. 134 A template provides a consistent format for the description of APIs 135 so that implementers can easily build interoperable clients and 136 servers, and other application designers can reuse application 137 components in their own applications. 139 2. Application Descriptions 141 A CoRE Application Description is a named set of reusable components. 142 It is comprised of: 144 o URI schemes that identify communication protocols, 146 o Internet media types that identify representation formats, 148 o link relation types that identify link semantics, 150 o form relation types that identify form semantics, and 152 o optionally, well-known locations. 154 Together, these components provide the specific, in-band instructions 155 for interfacing with a given service. 157 2.1. URI Schemes 159 The foundation of a hypertext-driven REST API are the communication 160 protocol(s) spoken between a client and a server. Although HTTP/1.1 161 [13] is by far the most common communication protocol for REST APIs, 162 a REST API should typically not be dependent on any specific 163 communication protocol. 165 The use of a particular protocol is guided by URI schemes [7]. URI 166 schemes specify the syntax and semantics of URI references [1] found 167 in links (Section 2.2.2) and forms (Section 2.2.3). 169 A URI scheme refers to a family of protocols, typically distinguished 170 by a version number. For example, the "http" URI scheme refers to 171 the three members of the HTTP family of protocols: HTTP/1.0 [10], 172 HTTP/1.1 [13] and HTTP/2 [8]. The specific HTTP version is 173 negotiated between the client and the server through version 174 indicators in the protocol or the TLS application-layer protocol 175 negotiation (ALPN) extension [17]. 177 IANA maintains a list of registered URI schemes at 178 . 180 2.2. Internet Media Types 182 One of the most important aspect of hypertext-driven communications 183 is the concept of Internet media types [2]. Media types are used to 184 label representations so that it is known how the representation 185 should be interpreted and how it is encoded. The core of a CoRE 186 application description should be one or more media types. 188 A media type identifies a versioned series of representation formats 189 (Section 2.2.1): a media type does not identify a particular version 190 of a representation format; rather, the media type identifies the 191 family, and includes provisions for version indicator(s) embedded in 192 the representations themselves to determine more precisely the nature 193 of how the data is to be interpreted [20]. A new media type is only 194 needed to designate a completely incompatible format [20]. 196 Media types consist of a top-level type and a subtype, structured 197 into trees [2]. Optionally, media types can have parameters. For 198 example, the media type "text/plain; charset=utf-8" is a subtype for 199 plain text under the "text" top-level type in the standards tree and 200 has a parameter "charset" set to "utf-8". 202 Media types can be further refined by structured type name suffixes 203 (e.g., "+xml" appended to the base subtype name; see Section 4.2.8 of 204 RFC 6838), or by subtype information embedded in the representations 205 themselves (e.g., "xmlns" declarations in XML documents [12]). 206 Structured type name suffixes should be preferred, because embedded 207 subtype information cannot be negotiated (e.g., using the CoAP Accept 208 option). 210 In CoAP, media types are combined with content coding information 211 [14] to indicate the "content format" [23] of a representation. 212 Content formats are assigned a numeric identifier that can be used 213 instead of the (typically much larger) textual name of the media type 214 in representation formats with space constraints. 216 A media type must be determined from in-band information (e.g., from 217 the CoAP Content-Format option). Clients must not assume a structure 218 from the application context or other out-of-band information. 220 IANA maintains a list of registered Internet media types at 221 . 223 IANA maintains a list of registered structured suffixes at 224 . 226 IANA maintains a list of registered CoAP content formats at 227 . 229 2.2.1. Representation Formats 231 In RESTful applications, clients and servers exchange representations 232 that capture the current or intended state of a resource and that are 233 labeled with a media type. A representation is a sequence of bytes 234 whose structure and semantics are specified by a representation 235 format: a set of rules for encoding information. 237 Representation formats should generally allow clients with different 238 goals, so they can do different things with the same data. The 239 specification of a representation format "describes a problem space, 240 not a prescribed relationship between client and server. Client and 241 server must share an understanding of the representations they're 242 passing back and forth, but they don't need to have the same idea of 243 what the problem is that needs to be solved." [21] 245 Representation formats and their specifications evolve over time. It 246 is part of the responsibility of the designer of a new version of a 247 format to try to insure both forward and backward compatibility: new 248 documents should work reasonably (with some fallback) with old 249 processors, and old documents should work reasonably with new 250 processors [20]. 252 Representation formats enable hypertext-driven applications when they 253 support the expression of hypermedia controls: links (Section 2.2.2) 254 and/or forms (Section 2.2.3). 256 It is beyond the scope of this document to specify how hypermedia 257 controls can be expressed. The appropriate syntax, when available, 258 is described by the representation format specification associated 259 with each media type. 261 2.2.2. Links 263 A link is the primary means for a client to change application state, 264 i.e., to navigate from one resource to another. A link is a typed 265 connection between two resources [5], and is comprised of: 267 o a context (usually the current resource), 269 o a link relation type that identifies the semantics of the link 270 (Section 2.3), 272 o a target resource URI, and 274 o optionally, attributes that further describe the link target. 276 A link can be viewed as a statement of the form "{context} has a 277 {relation type} resource at {target URI}, which has {target 278 attributes}" [5]. For example, the resource 279 could have a "terms-of-service" resource at , 280 which has the media type "text/html". 282 There are two special kinds of links: 284 o An embedding link is a link with the additional hint that it, when 285 processed, should be substituted with a representation of the 286 referenced resource. Thus, traversing an embedding link adds to 287 the application state, rather than replacing it. 289 The most well known example for an embedding link is the HTML 290 element. When a web browser processes this element, it 291 automatically dereferences the "src" and renders the returned 292 image in place of the element. 294 o A templated link is a link where the client constructs the target 295 resource URI from provided in-band instructions. The specific 296 rules for such instructions are described by the representation 297 format. URI Templates [3] provide a generic way to construct URIs 298 through variable expansion. 300 Templated links allow a client to construct resource URIs without 301 being coupled to the resource structure at the server (provided 302 that the client learns the template from a representation sent by 303 the server and does not have the template hard coded). 305 2.2.3. Forms 307 A form is the primary means for a client to change resource state. 308 It is comprised of: 310 o a context (usually the current resource), 312 o a form relation type that identifies the semantics of the form 313 (Section 2.4), 315 o a target resource URI, 317 o a submission method (PUT, POST, PATCH, or DELETE), and 319 o a description of a representation that the service accepts as part 320 of form submission. This description can be a set of form fields 321 or simply a list of acceptable media types. 323 A form can be viewed as an instruction of the form "To {relation 324 type} the {context}, make a {method} request to {target URI}". For 325 example, to "update" the resource , a 326 client should make a PUT request to . 328 Note: A form with a submission method of GET is, strictly speaking, 329 a templated link, since it provides a way to construct a URI and 330 does not change resource state. 332 2.3. Link Relation Types 334 A link relation type identifies the semantics of a link [5]. For 335 example, a link with the relation type "copyright" indicates that the 336 resource identified by the target URI is a statement of the copyright 337 terms applying to the current context. 339 Relation types are not to be confused with media types; they do not 340 identify the format of the representation that results when the link 341 is dereferenced. Rather, they only describe how the current context 342 is related to another resource. 344 IANA maintains a list of registered link relation types at 345 . 347 Applications that don't wish to register a relation type can use an 348 extension relation type, which is a URI that uniquely identifies the 349 relation type (similar to a URI used as an XML namespace names). For 350 example, an application can use "http://example.com/foo" as link 351 relation type without having to register it. 353 In order to minimize the overhead of link relation types in 354 representation formats with space constraints, link relation types 355 are assigned a numeric identifier that can be used in place of the 356 textual name of the link relation type (see also Section 6.2). For 357 example, the link relation type "copyright" has the numeric 358 identifier 12. 360 2.4. Form Relation Types 362 A form relation type identifies the semantics of a form. For 363 example, a form with the relation type "create-item" indicates that a 364 new item can be created within the current context by making a 365 request to the resource identified by the target URI. 367 IANA maintains a list of registered form relation types at 368 . 370 Similar to link relation types, applications can use extension 371 relation types when they don't wish to register a relation type. 373 Form relation types are also assigned a numeric identifier that can 374 be used in place of the form relation type name. 376 2.5. Well-Known Locations 378 Some applications may require the discovery of information about a 379 host (known as "site-wide metadata" in RFC 5785 [4]). For example, 380 RFC 6415 [18] defines a metadata document format for describing 381 hosts; similarly, RFC 6690 [22] defines a link format for the 382 discovery of resources hosted by a server. 384 Applications that need to define a resource for this kind of metadata 385 can register new "well-known locations". RFC 5785 [4] defines a path 386 prefix in "http" and "https" URIs for this purpose, "/.well-known/"; 387 RFC 7252 [23] extends this concept to "coap" and "coaps" URIs. 389 IANA maintains a list of registered well-known URIs at 390 . 392 3. Template 394 Application name: 396 URI schemes: 398 Media types: 400 Link relation types: 402 Form relation types: 404 Well-known locations: 406 Interoperability considerations: 408 Security considerations: 410 Contact: 412 Author/Change controller: 414 4. URI Design Considerations 416 URIs [1] are a cornerstone of RESTful applications. They enable 417 uniform identification of resources via URI schemes [7] and are used 418 every time a client interacts with a particular resource or when a 419 resource representation references another resource. 421 URIs often include structured application data in the path and query 422 components, such as paths in a filesystem or keys in a database. It 423 is common for many REST APIs to prescribe a fixed format for this 424 data. However, there are a number of problems with this practice 425 [6], in particular if the application designer and the server owner 426 are not the same entity. 428 Therefore, in hypertext-driven applications URIs are not included in 429 the application interface. A CoRE Application Description must not 430 mandate any particular form of URI substructure that is not 431 explicitly allowed by RFC 3986 [1]. 433 RFC 7320 [6] describes the problematic practice of fixed URI 434 structures in detail and provides some acceptable alternatives. 436 Even though URIs are not part of the application interface, the 437 design of the URI structure on a server is an essential part of 438 implementing a RESTful application. The server implementer is 439 responsible for binding the resources identified by the application 440 designer to URIs. 442 A good RESTful URI is: 444 o Short. Short URIs are easier to remember and cause less overhead 445 in requests and representations. 447 o Meaningful. A URI should describe the resource in a way that is 448 meaningful and useful to humans. 450 o Consistent. URIs should follow a consistent pattern to make it 451 easy to reason about the application. 453 o Bookmarkable. Cool URIs don't change [9]. However, application 454 resource structures change. That should naturally cause URIs to 455 change so they better reflect reality. So implementations should 456 not depend on unchanging URIs. 458 o Shareable. A URI should not be context sensitive, e.g., to the 459 currently logged-in user. It should be possible to share a URI 460 with third parties so they can access the same resource. 462 o Extension-less. Some applications return different data for 463 different extensions, e.g., for "contacts.xml" or "contacts.json". 464 But different URIs imply different resources. RESTful URIs should 465 identify a single resource. Different representations of the 466 resource can be negotiated (e.g., using the CoAP Accept option). 468 5. Security Considerations 470 The security considerations of RFC 3986 [1], RFC 5785 [4], RFC 5988 471 [5], RFC 6570 [3], RFC 6838 [2], RFC 7320 [6], and RFC 7595 [7] are 472 inherited. 474 All components of an application description are expected to contain 475 clear security considerations. CoRE Application Descriptions should 476 furthermore contain security considerations that need to be taken 477 into account for the security of the overall application. 479 6. IANA Considerations 481 [Note to RFC Editor: Please replace XXXX in this section with the RFC 482 number of this specification.] 484 6.1. Content-Format Registry 486 RFC 6838 [2] establishes a IANA registry for media types. Many of 487 these media types are also useful in constrained environments as CoAP 488 content formats. RFC 7252 [23] establishes a IANA registry for these 489 content formats. This specification tasks IANA with the allocation 490 of a content format for any existing or new media type registration 491 that does not define any parameters (required or optional). The 492 content formats shall be allocated in the range 1000-9999. 494 6.2. Link Relation Type Registry 496 RFC 5988 [5] establishes a IANA registry for link relation types. 497 This specification extends the registration template with a "Relation 498 ID": a numeric identifier that can be used instead of the "Relation 499 Name" to identify a link relation type. IANA is tasked with the 500 assignment of an ID to any existing or new link relation type. The 501 IDs shall be assigned in the range 1-9999. 503 6.3. Form Relation Type Registry 505 This specification establishes a IANA registry for form relation 506 types. 508 6.3.1. Registering New Form Relation Types 510 Form relation types are registered in the same way as link relation 511 types [5], i.e., they are registered on the advice of a Designated 512 Expert with a Specification Required. 514 The requirements for registered relation types are adopted from 515 Section 4.1 of RFC 5988 [5]. 517 The registration template is: 519 o Relation Name: 521 o Relation ID: 523 o Description: 525 o Reference: 527 o Notes: [optional] 529 The IDs shall be assigned in the range 1-9999. 531 6.3.2. Initial Registry Contents 533 The Form Relation Type registry's initial contents are: 535 o Relation Name: create-item 536 Relation ID: 1 537 Description: Refers to a resource that can be used to create a 538 resource in a collection of resources. 539 Reference: [RFCXXXX] 541 o Relation Name: delete 542 Relation ID: 2 543 Description: Refers to a resource that can be used to delete a 544 resource in a collection of resources. 545 Reference: [RFCXXXX] 547 o Relation Name: update 548 Relation ID: 3 549 Description: Refers to a resource that can be used to update the 550 state of the form's context. 551 Reference: [RFCXXXX] 553 7. References 555 7.1. Normative References 557 [1] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 558 Resource Identifier (URI): Generic Syntax", STD 66, 559 RFC 3986, DOI 10.17487/RFC3986, January 2005, 560 . 562 [2] Freed, N., Klensin, J., and T. Hansen, "Media Type 563 Specifications and Registration Procedures", BCP 13, 564 RFC 6838, DOI 10.17487/RFC6838, January 2013, 565 . 567 [3] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 568 and D. Orchard, "URI Template", RFC 6570, 569 DOI 10.17487/RFC6570, March 2012, 570 . 572 [4] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 573 Uniform Resource Identifiers (URIs)", RFC 5785, 574 DOI 10.17487/RFC5785, April 2010, 575 . 577 [5] Nottingham, M., "Web Linking", RFC 5988, 578 DOI 10.17487/RFC5988, October 2010, 579 . 581 [6] Nottingham, M., "URI Design and Ownership", BCP 190, 582 RFC 7320, DOI 10.17487/RFC7320, July 2014, 583 . 585 [7] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 586 and Registration Procedures for URI Schemes", BCP 35, 587 RFC 7595, DOI 10.17487/RFC7595, June 2015, 588 . 590 7.2. Informative References 592 [8] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 593 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 594 DOI 10.17487/RFC7540, May 2015, 595 . 597 [9] Berners-Lee, T., "Cool URIs don't change", 1998, 598 . 600 [10] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 601 Transfer Protocol -- HTTP/1.0", RFC 1945, 602 DOI 10.17487/RFC1945, May 1996, 603 . 605 [11] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 606 Constrained-Node Networks", RFC 7228, 607 DOI 10.17487/RFC7228, May 2014, 608 . 610 [12] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. 611 Thompson, "Namespaces in XML 1.0 (Third Edition)", World 612 Wide Web Consortium Recommendation REC-xml-names-20091208, 613 December 2009, 614 . 616 [13] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 617 Protocol (HTTP/1.1): Message Syntax and Routing", 618 RFC 7230, DOI 10.17487/RFC7230, June 2014, 619 . 621 [14] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 622 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 623 DOI 10.17487/RFC7231, June 2014, 624 . 626 [15] Fielding, R., "Architectural Styles and the Design of 627 Network-based Software Architectures", Ph.D. Dissertation, 628 University of California, Irvine, 2000, 629 . 632 [16] Fielding, R., "REST APIs must be hypertext-driven", 633 October 2008, . 636 [17] Friedl, S., Popov, A., Langley, A., and E. Stephan, 637 "Transport Layer Security (TLS) Application-Layer Protocol 638 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 639 July 2014, . 641 [18] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata", 642 RFC 6415, DOI 10.17487/RFC6415, October 2011, 643 . 645 [19] Li, L., Wei, Z., Luo, M., and W. Chou, "Requirements and 646 Design Patterns for REST Northbound API in SDN", draft-li- 647 sdnrg-design-restapi-02 (work in progress), July 2016. 649 [20] Masinter, L., "MIME and the Web", draft-masinter-mime-web- 650 info-02 (work in progress), January 2011. 652 [21] Richardson, L. and M. Amundsen, "RESTful Web APIs", 653 O'Reilly Media, ISBN 978-1-4493-5806-8, September 2013. 655 [22] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 656 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 657 . 659 [23] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 660 Application Protocol (CoAP)", RFC 7252, 661 DOI 10.17487/RFC7252, June 2014, 662 . 664 Acknowledgements 666 Jan Algermissen, Mike Amundsen, Mike Kelly, Julian Reschke, and Erik 667 Wilde provided valuable input on link and form relation types. 669 Thanks to Olaf Bergmann, Carsten Bormann, Stefanie Gerdes, Ari 670 Keranen, Michael Koster, Matthias Kovatsch, Teemu Savolainen, and 671 Bilhanan Silverajan for helpful comments and discussions that have 672 shaped the document. 674 Some of the text in this document has been borrowed from [5], [6], 675 [16], [19], and [20]. All errors are my own. 677 This work was funded in part by Nokia. 679 Author's Address 681 Klaus Hartke 682 Universitaet Bremen TZI 683 Postfach 330440 684 Bremen D-28359 685 Germany 687 Phone: +49-421-218-63905 688 Email: hartke@tzi.org