idnits 2.17.1 draft-keranen-t2trg-rest-iot-05.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 389 has weird spacing: '... query frag...' -- The document date (September 14, 2017) is 2415 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-core-object-security' is defined on line 1044, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-04 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-11 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-02 == Outdated reference: A later version (-16) exists of draft-ietf-core-senml-10 == Outdated reference: A later version (-16) exists of draft-irtf-t2trg-iot-seccons-05 -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 7320 (Obsoleted by RFC 8820) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Keranen 3 Internet-Draft Ericsson 4 Intended status: Informational M. Kovatsch 5 Expires: March 18, 2018 ETH Zurich 6 K. Hartke 7 Universitaet Bremen TZI 8 September 14, 2017 10 RESTful Design for Internet of Things Systems 11 draft-keranen-t2trg-rest-iot-05 13 Abstract 15 This document gives guidance for designing Internet of Things (IoT) 16 systems that follow the principles of the Representational State 17 Transfer (REST) architectural style. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 18, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 6 57 3.2. System design . . . . . . . . . . . . . . . . . . . . . . 8 58 3.3. Uniform Resource Identifiers (URIs) . . . . . . . . . . . 9 59 3.4. Representations . . . . . . . . . . . . . . . . . . . . . 10 60 3.5. HTTP/CoAP Methods . . . . . . . . . . . . . . . . . . . . 10 61 3.5.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 3.5.2. POST . . . . . . . . . . . . . . . . . . . . . . . . 11 63 3.5.3. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 3.5.4. DELETE . . . . . . . . . . . . . . . . . . . . . . . 12 65 3.6. HTTP/CoAP Status/Response Codes . . . . . . . . . . . . . 12 66 4. REST Constraints . . . . . . . . . . . . . . . . . . . . . . 13 67 4.1. Client-Server . . . . . . . . . . . . . . . . . . . . . . 13 68 4.2. Stateless . . . . . . . . . . . . . . . . . . . . . . . . 14 69 4.3. Cache . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 4.4. Uniform Interface . . . . . . . . . . . . . . . . . . . . 14 71 4.5. Layered System . . . . . . . . . . . . . . . . . . . . . 15 72 4.6. Code-on-Demand . . . . . . . . . . . . . . . . . . . . . 15 73 5. Hypermedia-driven Applications . . . . . . . . . . . . . . . 16 74 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 16 75 5.2. Knowledge . . . . . . . . . . . . . . . . . . . . . . . . 17 76 5.3. Interaction . . . . . . . . . . . . . . . . . . . . . . . 18 77 6. Design Patterns . . . . . . . . . . . . . . . . . . . . . . . 18 78 6.1. Collections . . . . . . . . . . . . . . . . . . . . . . . 18 79 6.2. Calling a Procedure . . . . . . . . . . . . . . . . . . . 19 80 6.2.1. Instantly Returning Procedures . . . . . . . . . . . 19 81 6.2.2. Long-running Procedures . . . . . . . . . . . . . . . 19 82 6.2.3. Conversion . . . . . . . . . . . . . . . . . . . . . 20 83 6.2.4. Events as State . . . . . . . . . . . . . . . . . . . 20 84 6.3. Server Push . . . . . . . . . . . . . . . . . . . . . . . 21 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 86 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 23 89 9.2. Informative References . . . . . . . . . . . . . . . . . 25 90 Appendix A. Future Work . . . . . . . . . . . . . . . . . . . . 26 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 93 1. Introduction 95 The Representational State Transfer (REST) architectural style [REST] 96 is a set of guidelines and best practices for building distributed 97 hypermedia systems. At its core is a set of constraints, which when 98 fulfilled enable desirable properties for distributed software 99 systems such as scalability and modifiability. When REST principles 100 are applied to the design of a system, the result is often called 101 RESTful and in particular an API following these principles is called 102 a RESTful API. 104 Different protocols can be used with RESTful systems, but at the time 105 of writing the most common protocols are HTTP [RFC7230] and CoAP 106 [RFC7252]. Since RESTful APIs are often simple and lightweight, they 107 are a good fit for various IoT applications. The goal of this 108 document is to give basic guidance for designing RESTful systems and 109 APIs for IoT applications and give pointers for more information. 110 Design of a good RESTful IoT system has naturally many commonalities 111 with other Web systems. Compared to other systems, the key 112 characteristics of many IoT systems include: 114 o data formats, interaction patterns, and other mechanisms that 115 minimize, or preferably avoid, the need for human interaction 117 o preference for compact and simple data formats to facilitate 118 efficient transfer over (often) constrained networks and 119 lightweight processing in constrained nodes 121 2. Terminology 123 This section explains some of the common terminology that is used in 124 the context of RESTful design for IoT systems. For terminology of 125 constrained nodes and networks, see [RFC7228]. 127 Cache: A local store of response messages and the subsystem that 128 controls storage, retrieval, and deletion of messages in it. 130 Client: A node that sends requests to servers and receives 131 responses. In RESTful IoT systems it's common for nodes to have 132 more than one role (e.g., both server and client; see 133 Section 3.1). 135 Client State: The state kept by a client between requests. This 136 typically includes the currently processed representation, the set 137 of active requests, the history of requests, bookmarks (URIs 138 stored for later retrieval), and application-specific state (e.g., 139 local variables). (Note that this is called "Application State" 140 in [REST], which has some ambiguity in modern (IoT) systems where 141 the overall state of the distributed application (i.e., 142 application state) is reflected in the union of all Client States 143 and Resource States of all clients and servers involved.) 145 Content Negotiation: The practice of determining the "best" 146 representation for a client when examining the current state of a 147 resource. The most common forms of content negotiation are 148 Proactive Content Negotiation and Reactive Content Negotiation. 150 Form: A hypermedia control that enables a client to change the state 151 of a resource or to construct a query locally. 153 Forward Proxy: An intermediary that is selected by a client, usually 154 via local configuration rules, and that can be tasked to make 155 requests on behalf of the client. This may be useful, for 156 example, when the client lacks the capability to make the request 157 itself or to service the response from a cache in order to reduce 158 response time, network bandwidth, and energy consumption. 160 Gateway: A reverse proxy that provides an interface to a non-RESTful 161 system such as legacy systems or alternative technologies such as 162 Bluetooth ATT/GATT. See also "Reverse Proxy". 164 Hypermedia Control: A component, such as a link or a form, embedded 165 in a representation that identifies a resource for future 166 hypermedia interactions. If the client engages in an interaction 167 with the identified resource, the result may be a change to 168 resource state and/or client state. 170 Idempotent Method: A method where multiple identical requests with 171 that method lead to the same visible resource state as a single 172 such request. 174 Link: A hypermedia control that enables a client to navigate between 175 resources and thereby change the client state. 177 Link Relation Type: An identifier that describes how the link target 178 resource relates to the current resource (see [RFC5988]). 180 Media Type: A string such as "text/html" or "application/json" that 181 is used to label representations so that it is known how the 182 representation should be interpreted and how it is encoded. 184 Method: An operation associated with a resource. Common methods 185 include GET, PUT, POST, and DELETE (see Section 3.5 for details). 187 Origin Server: A server that is the definitive source for 188 representations of its resources and the ultimate recipient of any 189 request that intends to modify its resources. In contrast, 190 intermediaries (such as proxies caching a representation) can 191 assume the role of a server, but are not the source for 192 representations as these are acquired from the origin server. 194 Proactive Content Negotiation: A content negotiation mechanism where 195 the server selects a representation based on the expressed 196 preference of the client. For example, an IoT application could 197 send a request to a sensor with preferred media type "application/ 198 senml+json". 200 Reactive Content Negotiation: A content negotiation mechanism where 201 the client selects a representation from a list of available 202 representations. The list may, for example, be included by a 203 server in an initial response. If the user agent is not satisfied 204 by the initial response representation, it can request one or more 205 of the alternative representations, selected based on metadata 206 (e.g., available media types) included in the response. 208 Representation: A serialization that represents the current or 209 intended state of a resource and that can be transferred between 210 clients and servers. REST requires representations to be self- 211 describing, meaning that there must be metadata that allows peers 212 to understand which representation format is used. Depending on 213 the protocol needs and capabilities, there can be additional 214 metadata that is transmitted along with the representation. 216 Representation Format: A set of rules for serializing resource 217 state. On the Web, the most prevalent representation format is 218 HTML. Other common formats include plain text and formats based 219 on JSON [RFC7159], XML, or RDF. Within IoT systems, often compact 220 formats based on JSON, CBOR [RFC7049], and EXI 221 [W3C.REC-exi-20110310] are used. 223 Representational State Transfer (REST): An architectural style for 224 Internet-scale distributed hypermedia systems. 226 Resource: An item of interest identified by a URI. Anything that 227 can be named can be a resource. A resource often encapsulates a 228 piece of state in a system. Typical resources in an IoT system 229 can be, e.g., a sensor, the current value of a sensor, the 230 location of a device, or the current state of an actuator. 232 Resource State: A model of a resource's possible states that is 233 represented in a supported representation type, typically a media 234 type. Resources can change state because of REST interactions 235 with them, or they can change state for reasons outside of the 236 REST model. 238 Resource Type: An identifier that annotates the application- 239 semantics of a resource (see Section 3.1 of [RFC6690]). 241 Reverse Proxy: An intermediary that appears as a server towards the 242 client but satisfies the requests by forwarding them to the actual 243 server (possibly via one or more other intermediaries). A reverse 244 proxy is often used to encapsulate legacy services, to improve 245 server performance through caching, and to enable load balancing 246 across multiple machines. 248 Safe Method: A method that does not result in any state change on 249 the origin server when applied to a resource. 251 Server: A node that listens for requests, performs the requested 252 operation and sends responses back to the clients. 254 Uniform Resource Identifier (URI): A global identifier for 255 resources. See Section 3.3 for more details. 257 3. Basics 259 3.1. Architecture 261 The components of a RESTful system are assigned one or both of two 262 roles: client or server. Note that the terms "client" and "server" 263 refer only to the roles that the nodes assume for a particular 264 message exchange. The same node might act as a client in some 265 communications and a server in others. Classic user agents (e.g., 266 Web browsers) are always in the client role and have the initiative 267 to issue requests. Origin servers always have the server role and 268 govern over the resources they host. 270 ________ _________ 271 | | | | 272 | User (C)-------------------(S) Origin | 273 | Agent | | Server | 274 |________| |_________| 275 (Browser) (Web Server) 277 Figure 1: Client-Server Communication 279 Intermediaries (such as forward proxies, reverse proxies, and 280 gateways) implement both roles, but only forward requests to other 281 intermediaries or origin servers. They can also translate requests 282 to different protocols, for instance, as CoAP-HTTP cross-proxies. 284 ________ __________ _________ 285 | | | | | | 286 | User (C)---(S) Inter- (C)--------------------(S) Origin | 287 | Agent | | mediary | | Server | 288 |________| |__________| |_________| 289 (Browser) (Forward Proxy) (Web Server) 291 Figure 2: Communication with Forward Proxy 293 Reverse proxies are usually imposed by the origin server. In 294 addition to the features of a forward proxy, they can also provide an 295 interface for non-RESTful services such as legacy systems or 296 alternative technologies such as Bluetooth ATT/GATT. In this case, 297 reverse proxies are usually called gateways. This property is 298 enabled by the Layered System constraint of REST, which says that a 299 client cannot see beyond the server it is connected to (i.e., it is 300 left unaware of the protocol/paradigm change). 302 ________ __________ _________ 303 | | | | | | 304 | User (C)--------------------(S) Inter- (x)---(x) Origin | 305 | Agent | | mediary | | Server | 306 |________| |__________| |_________| 307 (Browser) (Gateway) (Legacy System) 309 Figure 3: Communication with Reverse Proxy 311 Nodes in IoT systems often implement both roles. Unlike 312 intermediaries, however, they can take the initiative as a client 313 (e.g., to register with a directory, such as CoRE Resource Directory 314 [I-D.ietf-core-resource-directory], or to interact with another 315 thing) and act as origin server at the same time (e.g., to serve 316 sensor values or provide an actuator interface). 318 ________ _________ 319 | | | | 320 | Thing (C)-------------------------------------(S) Origin | 321 | (S) | Server | 322 |________| \ |_________| 323 (Sensor) \ ________ (Resource Directory) 324 \ | | 325 (C) Thing | 326 |________| 327 (Controller) 329 Figure 4: Constrained RESTful environments 331 3.2. System design 333 When designing a RESTful system, the primary effort goes into 334 modeling the state of the distributed application and assigning it to 335 the different components (i.e., clients and servers). How clients 336 can navigate through the resources and modify state to achieve their 337 goals is defined through hypermedia controls, that is, links and 338 forms. Hypermedia controls span a kind of a state machine where the 339 nodes are resources and the transitions are links or forms. Clients 340 run this state machine (i.e., the application) by retrieving 341 representations, processing the data, and following the included 342 hypermedia controls. In REST, remote state is changed by submitting 343 forms. This is usually done by retrieving the current state, 344 modifying the state on the client side, and transferring the new 345 state to the server in the form of new representations - rather than 346 calling a service and modifying the state on the server side. 348 Client state encompasses the current state of the described state 349 machine and the possible next transitions derived from the hypermedia 350 controls within the currently processed representation (see 351 Section 2). Furthermore, clients can have part of the state of the 352 distributed application in local variables. 354 Resource state includes the more persistent data of an application 355 (i.e., independent of individual clients). This can be static data 356 such as device descriptions, persistent data such as system 357 configurations, but also dynamic data such as the current value of a 358 sensor on a thing. 360 It is important to distinguish between "client state" and "resource 361 state" and keep them separate. Following the Stateless constraint, 362 the client state must be kept only on clients. That is, there is no 363 establishment of shared information about past and future 364 interactions between client and server (usually called a session). 365 On the one hand, this makes requests a bit more verbose since every 366 request must contain all the information necessary to process it. On 367 the other hand, this makes servers efficient and scalable, since they 368 do not have to keep any state about their clients. Requests can 369 easily be distributed over multiple worker threads or server 370 instances. For IoT systems, this constraint lowers the memory 371 requirements for server implementations, which is particularly 372 important for constrained servers (e.g., sensor nodes) and servers 373 serving large amount of clients (e.g., Resource Directory). 375 3.3. Uniform Resource Identifiers (URIs) 377 An important part of RESTful API design is to model the system as a 378 set of resources whose state can be retrieved and/or modified and 379 where resources can be potentially also created and/or deleted. 381 Uniform Resource Identifiers (URIs) are used to indicate a resource 382 for interaction, to reference a resource from another resource, to 383 advertise or bookmark a resource, or to index a resource by search 384 engines. 386 foo://example.com:8042/over/there?name=ferret#nose 387 \_/ \______________/\_________/ \_________/ \__/ 388 | | | | | 389 scheme authority path query fragment 391 A URI is a sequence of characters that matches the syntax defined in 392 [RFC3986]. It consists of a hierarchical sequence of five 393 components: scheme, authority, path, query, and fragment (from most 394 significant to least significant). A scheme creates a namespace for 395 resources and defines how the following components identify a 396 resource within that namespace. The authority identifies an entity 397 that governs part of the namespace, such as the server 398 "www.example.org" in the "http" scheme. A host name (e.g., a fully 399 qualified domain name) or an IP address, potentially followed by a 400 transport layer port number, are usually used in the authority 401 component for the "http" and "coap" schemes. The path and query 402 contain data to identify a resource within the scope of the URI's 403 scheme and naming authority. The fragment allows to refer to some 404 portion of the resource, such as a Record in a SenML Pack. However, 405 fragments are processed only at client side and not sent on the wire. 406 [RFC7320] provides more details on URI design and ownership with best 407 current practices for establishing URI structures, conventions, and 408 formats. 410 For RESTful IoT applications, typical schemes include "https", 411 "coaps", "http", and "coap". These refer to HTTP and CoAP, with and 412 without Transport Layer Security (TLS) [RFC5246]. (CoAP uses 413 Datagram TLS (DTLS) [RFC6347], the variant of TLS for UDP.) These 414 four schemes also provide means for locating the resource; using the 415 HTTP protocol for "http" and "https", and with the CoAP protocol for 416 "coap" and "coaps". If the scheme is different for two URIs (e.g., 417 "coap" vs. "coaps"), it is important to note that even if the rest of 418 the URI is identical, these are two different resources, in two 419 distinct namespaces. 421 The query parameters can be used to parametrize the resource. For 422 example, a GET request may use query parameters to request the server 423 to send only certain kind data of the resource (i.e., filtering the 424 response). Query parameters in PUT and POST requests do not have 425 such established semantics and are not commonly used. Whether the 426 order of the query parameters matters in URIs is unspecified and they 427 can be re-ordered e.g., by proxies. Therefore applications should 428 not rely on their order; see Section 3.3 of [RFC6943] for more 429 details. 431 3.4. Representations 433 Clients can retrieve the resource state from an origin server or 434 manipulate resource state on the origin server by transferring 435 resource representations. Resource representations have a media type 436 that tells how the representation should be interpreted by 437 identifying the representation format used. 439 Typical media types for IoT systems include: 441 o "text/plain" for simple UTF-8 text 443 o "application/octet-stream" for arbitrary binary data 445 o "application/json" for the JSON format [RFC7159] 447 o "application/senml+json" [I-D.ietf-core-senml] for Sensor Markup 448 Language (SenML) formatted data 450 o "application/cbor" for CBOR [RFC7049] 452 o "application/exi" for EXI [W3C.REC-exi-20110310] 454 A full list of registered Internet Media Types is available at the 455 IANA registry [IANA-media-types] and numerical media types registered 456 for use with CoAP are listed at CoAP Content-Formats IANA registry 457 [IANA-CoAP-media]. 459 3.5. HTTP/CoAP Methods 461 Section 4.3 of [RFC7231] defines the set of methods in HTTP; 462 Section 5.8 of [RFC7252] defines the set of methods in CoAP. As part 463 of the Uniform Interface constraint, each method can have certain 464 properties that give guarantees to clients. 466 Safe methods do not cause any state change on the origin server when 467 applied to a resource. For example, the GET method only returns a 468 representation of the resource state but does not change the 469 resource. Thus, it is always safe for a client to retrieve a 470 representation without affecting server-side state. 472 Idempotent methods can be applied multiple times to the same resource 473 while causing the same visible resource state as a single such 474 request. For example, the PUT method replaces the state of a 475 resource with a new state; replacing the state multiple times with 476 the same new state still results in the same state for the resource. 477 However, the response from the server can be different when the same 478 idempotent method is used multiple times. For example when DELETE is 479 used twice on an existing resource, the first request would remove 480 the association and return success acknowledgement whereas the second 481 request would likely result in error response due to non-existing 482 resource. 484 The following lists the most relevant methods and gives a short 485 explanation of their semantics. 487 3.5.1. GET 489 The GET method requests a current representation for the target 490 resource, while the origin server must ensure that there are no side- 491 effects on the resource state. Only the origin server needs to know 492 how each of its resource identifiers corresponds to an implementation 493 and how each implementation manages to select and send a current 494 representation of the target resource in a response to GET. 496 A payload within a GET request message has no defined semantics. 498 The GET method is safe and idempotent. 500 3.5.2. POST 502 The POST method requests that the target resource process the 503 representation enclosed in the request according to the resource's 504 own specific semantics. 506 If one or more resources has been created on the origin server as a 507 result of successfully processing a POST request, the origin server 508 sends a 201 (Created) response containing a Location header field 509 (with HTTP) or Location-Path and/or Location-Query Options (with 510 CoAP) that provide an identifier for the resource created. The 511 server also includes a representation that describes the status of 512 the request while referring to the new resource(s). 514 The POST method is not safe nor idempotent. 516 3.5.3. PUT 518 The PUT method requests that the state of the target resource be 519 created or replaced with the state defined by the representation 520 enclosed in the request message payload. A successful PUT of a given 521 representation would suggest that a subsequent GET on that same 522 target resource will result in an equivalent representation being 523 sent. 525 The fundamental difference between the POST and PUT methods is 526 highlighted by the different intent for the enclosed representation. 527 The target resource in a POST request is intended to handle the 528 enclosed representation according to the resource's own semantics, 529 whereas the enclosed representation in a PUT request is defined as 530 replacing the state of the target resource. Hence, the intent of PUT 531 is idempotent and visible to intermediaries, even though the exact 532 effect is only known by the origin server. 534 The PUT method is not safe, but is idempotent. 536 3.5.4. DELETE 538 The DELETE method requests that the origin server remove the 539 association between the target resource and its current 540 functionality. 542 If the target resource has one or more current representations, they 543 might or might not be destroyed by the origin server, and the 544 associated storage might or might not be reclaimed, depending 545 entirely on the nature of the resource and its implementation by the 546 origin server. 548 The DELETE method is not safe, but is idempotent. 550 3.6. HTTP/CoAP Status/Response Codes 552 Section 6 of [RFC7231] defines a set of Status Codes in HTTP that are 553 used by application to indicate whether a request was understood and 554 satisfied, and how to interpret the answer. Similarly, Section 5.9 555 of [RFC7252] defines the set of Response Codes in CoAP. 557 The status codes consist of three digits (e.g., "404" with HTTP or 558 "4.04" with CoAP) where the first digit expresses the class of the 559 code. Implementations do not need to understand all status codes, 560 but the class of the code must be understood. Codes starting with 1 561 are informational; the request was received and being processed. 562 Codes starting with 2 indicate a successful request. Codes starting 563 with 3 indicate redirection; further action is needed to complete the 564 request. Codes stating with 4 and 5 indicate errors. The codes 565 starting with 4 mean client error (e.g., bad syntax in the request) 566 whereas codes starting with 5 mean server error; there was no 567 apparent problem with the request, but server was not able to fulfill 568 the request. 570 Responses may be stored in a cache to satisfy future, equivalent 571 requests. HTTP and CoAP use two different patterns to decide what 572 responses are cacheable. In HTTP, the cacheability of a response 573 depends on the request method (e.g., responses returned in reply to a 574 GET request are cacheable). In CoAP, the cacheability of a response 575 depends on the response code (e.g., responses with code 2.04 are 576 cacheable). This difference also leads to slightly different 577 semantics for the codes starting with 2; for example, CoAP does not 578 have a 2.00 response code whereas 200 ("OK") is commonly used with 579 HTTP. 581 4. REST Constraints 583 The REST architectural style defines a set of constraints for the 584 system design. When all constraints are applied correctly, REST 585 enables architectural properties of key interest [REST]: 587 o Performance 589 o Scalability 591 o Reliability 593 o Simplicity 595 o Modifiability 597 o Visibility 599 o Portability 601 The following sub-sections briefly summarize the REST constraints and 602 explain how they enable the listed properties. 604 4.1. Client-Server 606 As explained in the Architecture section, RESTful system components 607 have clear roles in every interaction. Clients have the initiative 608 to issue requests, intermediaries can only forward requests, and 609 servers respond requests, while origin servers are the ultimate 610 recipient of requests that intent to modify resource state. 612 This improves simplicity and visibility, as it is clear which 613 component started an interaction. Furthermore, it improves 614 modifiability through a clear separation of concerns. 616 4.2. Stateless 618 The Stateless constraint requires messages to be self-contained. 619 They must contain all the information to process it, independent from 620 previous messages. This allows to strictly separate the client state 621 from the resource state. 623 This improves scalability and reliability, since servers or worker 624 threads can be replicated. It also improves visibility because 625 message traces contain all the information to understand the logged 626 interactions. 628 Furthermore, the Stateless constraint enables caching. 630 4.3. Cache 632 This constraint requires responses to have implicit or explicit 633 cache-control metadata. This enables clients and intermediary to 634 store responses and re-use them to locally answer future requests. 635 The cache-control metadata is necessary to decide whether the 636 information in the cached response is still fresh or stale and needs 637 to be discarded. 639 Cache improves performance, as less data needs to be transferred and 640 response times can be reduced significantly. Less transfers also 641 improves scalability, as origin servers can be protected from too 642 many requests. Local caches furthermore improve reliability, since 643 requests can be answered even if the origin server is temporarily not 644 available. 646 4.4. Uniform Interface 648 All RESTful APIs use the same, uniform interface independent of the 649 application. This simple interaction model is enabled by exchanging 650 representations and modifying state locally, which simplifies the 651 interface between clients and servers to a small set of methods to 652 retrieve, update, and delete state - which applies to all 653 applications. 655 In contrast, in a service-oriented RPC approach, all required ways to 656 modify state need to be modeled explicitly in the interface resulting 657 in a large set of methods - which differs from application to 658 application. Moreover, it is also likely that different parties come 659 up with different ways how to modify state, including the naming of 660 the procedures, while the state within an application is a bit easier 661 to agree on. 663 A REST interface is fully defined by: 665 o URIs to identify resources 667 o representation formats to represent (and retrieve and manipulate) 668 resource state 670 o self-descriptive messages with a standard set of methods (e.g., 671 GET, POST, PUT, DELETE with their guaranteed properties) 673 o hypermedia controls within representations 675 The concept of hypermedia controls is also known as HATEOAS: 676 Hypermedia As The Engine Of Application State. The origin server 677 embeds controls for the interface into its representations and 678 thereby informs the client about possible next requests. The mostly 679 used control for RESTful systems is Web Linking [RFC5590]. 680 Hypermedia forms are more powerful controls that describe how to 681 construct more complex requests, including representations to modify 682 resource state. 684 While this is the most complex constraints (in particular the 685 hypermedia controls), it improves many different key properties. It 686 improves simplicity, as uniform interfaces are easier to understand. 687 The self-descriptive messages improve visibility. The limitation to 688 a known set of representation formats fosters portability. Most of 689 all, however, this constraint is the key to modifiability, as 690 hypermedia-driven, uniform interfaces allow clients and servers to 691 evolve independently, and hence enable a system to evolve. 693 4.5. Layered System 695 This constraint enforces that a client cannot see beyond the server 696 with which it is interacting. 698 A layered system is easier to modify, as topology changes become 699 transparent. Furthermore, this helps scalability, as intermediaries 700 such as load balancers can be introduced without changing the client 701 side. The clean separation of concerns helps with simplicity. 703 4.6. Code-on-Demand 705 This principle enables origin servers to ship code to clients. 707 Code-on-Demand improves modifiability, since new features can be 708 deployed during runtime (e.g., support for a new representation 709 format). It also improves performance, as the server can provide 710 code for local pre-processing before transferring the data. 712 5. Hypermedia-driven Applications 714 Hypermedia-driven applications take advantage of hypermedia controls, 715 i.e., links and forms, embedded in the resource representations. A 716 hypermedia client is a client that is capable of processing these 717 hypermedia controls. Hypermedia links can be used to give additional 718 information about a resource representation (e.g., the source URI of 719 the representation) or pointing to other resources. The forms can be 720 used to describe the structure of the data that can be sent (e.g., 721 with a POST or PUT method) to a server, or how a data retrieval 722 (e.g., GET) request for a resource should be formed. In a 723 hypermedia-driven application the client interacts with the server 724 using only the hypermedia controls, instead of selecting methods and/ 725 or constructing URIs based on out-of-band information, such as API 726 documentation. 728 5.1. Motivation 730 The advantage of this approach is increased evolvability and 731 extensibility. This is important in scenarios where servers exhibit 732 a range of feature variations, where it's expensive to keep evolving 733 client knowledge and server knowledge in sync all the time, or where 734 there are many different client and server implementations. 735 Hypermedia controls serve as indicators in capability negotiation. 736 In particular, they describe available resources and possible 737 operations on these resources using links and forms, respectively. 739 There are multiple reasons why a server might introduce new links or 740 forms: 742 o The server implements a newer version of the application. Older 743 clients ignore the new links and forms, while newer clients are 744 able to take advantage of the new features by following the new 745 links and submitting the new forms. 747 o The server offers links and forms depending on the current state. 748 The server can tell the client which operations are currently 749 valid and thus help the client navigate the application state 750 machine. The client does not have to have knowledge which 751 operations are allowed in the current state or make a request just 752 to find out that the operation is not valid. 754 o The server offers links and forms depending on the client's access 755 control rights. If the client is unauthorized to perform a 756 certain operation, then the server can simply omit the links and 757 forms for that operation. 759 5.2. Knowledge 761 A client needs to have knowledge of a couple of things for successful 762 interaction with a server. This includes what resources are 763 available, what representations of resource states are available, 764 what each representation describes, how to retrieve a representation, 765 what state changing operations on a resource are possible, how to 766 perform these operations, and so on. 768 Some part of this knowledge, such as how to retrieve the 769 representation of a resource state, is typically hard-coded in the 770 client software. For other parts, a choice can often be made between 771 hard-coding the knowledge or acquiring it on-demand. The key to 772 success in either case is the use in-band information for identifying 773 the knowledge that is required. This enables the client to verify 774 that is has all required knowledge and to acquire missing knowledge 775 on-demand. 777 A hypermedia-driven application typically uses the following 778 identifiers: 780 o URI schemes that identify communication protocols, 782 o Internet Media Types that identify representation formats, 784 o link relation types or resource types that identify link 785 semantics, 787 o form relation types that identify form semantics, 789 o variable names that identify the semantics of variables in 790 templated links, and 792 o form field names that identify the semantics of form fields in 793 forms. 795 The knowledge about these identifiers as well as matching 796 implementations have to be shared a priori in a RESTful system. 798 5.3. Interaction 800 A client begins interacting with an application through a GET request 801 on an entry point URI. The entry point URI is the only URI a client 802 is expected to know before interacting with an application. From 803 there, the client is expected to make all requests by following links 804 and submitting forms that are provided in previous responses. The 805 entry point URI can be obtained, for example, by manual configuration 806 or some discovery process (e.g., DNS-SD [RFC6763] or Resource 807 Directory [I-D.ietf-core-resource-directory]). For Constrained 808 RESTful environments "/.well-known/core" relative URI is defined as a 809 default entry point for requesting the links hosted by servers with 810 known or discovered addresses [RFC6690]. 812 6. Design Patterns 814 Certain kinds of design problems are often recurring in variety of 815 domains, and often re-usable design patterns can be applied to them. 816 Also some interactions with a RESTful IoT system are straightforward 817 to design; a classic example of reading a temperature from a 818 thermometer device is almost always implemented as a GET request to a 819 resource that represents the current value of the thermometer. 820 However, certain interactions, for example data conversions or event 821 handling, do not have as straightforward and well established ways to 822 represent the logic with resources and REST methods. 824 The following sections describe how common design problems such as 825 different interactions can be modeled with REST and what are the 826 benefits of different approaches. 828 6.1. Collections 830 A common pattern in RESTful systems across different domains is the 831 collection. A collection can be used to combine multiple resources 832 together by providing resources that consist of set of (often 833 partial) representations of resources, called items, and links to 834 resources. The collection resource also defines hypermedia controls 835 for managing and searching the items in the collection. 837 Examples of the collection pattern in RESTful IoT systems are the 838 CoRE Resource Directory [I-D.ietf-core-resource-directory], CoAP pub/ 839 sub broker [I-D.ietf-core-coap-pubsub], and resource discovery via 840 ".well-known/core". Collection+JSON [CollectionJSON] is an example 841 of a generic collection Media Type. 843 6.2. Calling a Procedure 845 To modify resource state, clients usually use GET to retrieve a 846 representation from the server, modify that locally, and transfer the 847 resulting state back to the server with a PUT (see Section 4.4). 848 Sometimes, however, the state can only be modified on the server 849 side, for instance, because representations would be too large to 850 transfer or part of the required information shall not be accessible 851 to clients. In this case, resource state is modified by calling a 852 procedure (or "function"). This is usually modeled with a POST 853 request, as this method leaves the behavior semantics completely to 854 the server. Procedure calls can be divided into two different 855 classes based on how long they are expected to execute: "instantly" 856 returning and long-running. 858 6.2.1. Instantly Returning Procedures 860 When the procedure can return within the expected response time of 861 the system, the result can be directly returned in the response. The 862 result can either be actual content or just a confirmation that the 863 call was successful. In either case, the response does not contain a 864 representation of the resource, but a so-called action result. 865 Action results can still have hypermedia controls to provide the 866 possible transitions in the application state machine. 868 6.2.2. Long-running Procedures 870 When the procedure takes longer than the expected response time of 871 the system, or even longer than the response timeout, it is a good 872 pattern to create a new resource to track the "task" execution. The 873 server would respond instantly with a "Created" status (HTTP code 201 874 or CoAP 2.01) and indicate the location of the task resource in the 875 corresponding header field (or CoAP option) or as a link in the 876 action result. The created resource can be used to monitor the 877 progress, to potentially modify queued tasks or cancel tasks, and to 878 eventually retrieve the result. 880 Monitoring information would be modeled as state of the task 881 resource, and hence be retrievable as representation. The result - 882 when available - can be embedded in the representation or given as a 883 link to another sub-resource. Modifying tasks can be modeled with 884 forms that either update sub-resources via PUT or do a partial write 885 using PATCH or POST. Canceling a task would be modeled with a form 886 that uses DELETE to remove the task resource. 888 6.2.3. Conversion 890 A conversion service is a good example where REST resources need to 891 behave more like a procedure call. The knowledge of converting from 892 one representation to another is located only at the server to 893 relieve clients from high processing or storing lots of data. There 894 are different approaches that all depend on the particular conversion 895 problem. 897 As mentioned in the previous sections, POST request are a good way to 898 model functionality that does not necessarily affect resource state. 899 When the input data for the conversion is small and the conversion 900 result is deterministic, however, it can be better to use a GET 901 request with the input data in the URI query part. The query is 902 parameterizing the conversion resource, so that it acts like a look- 903 up table. The benefit is that results can be cached also for HTTP 904 (where responses to POST are not cacheable). In CoAP, cacheability 905 depends on the response code, so that also a response to a POST 906 request can be made cacheable through a 2.05 Content code. 908 When the input data is large or has a binary encoding, it is better 909 to use POST requests with a proper Media Type for the input 910 representation. A POST request is also more suitable, when the 911 result is time-dependent and the latest result is expected (e.g., 912 exchange rates). 914 6.2.4. Events as State 916 In event-centric paradigms such as pub/sub, events are usually 917 represented by an incoming message that might even be identical for 918 each occurrence. Since the messages are queued, the receiver is 919 aware of each occurrence of the event and can react accordingly. For 920 instance, in an event-centric system, ringing a door bell would 921 result in a message being sent that represents the event that it was 922 rung. 924 In resource-oriented paradigms such as REST, messages usually carry 925 the current state of the remote resource, independent from the 926 changes (i.e., events) that have lead to that state. In a naive yet 927 natural design, a door bell could be modeled as a resource that can 928 have the states unpressed and pressed. There are, however, a few 929 issues with this approach. Polling is not an option, as it is highly 930 unlikely to be able to observe the pressed state with any realistic 931 polling interval. When using CoAP Observe with Confirmable 932 notifications, the server will usually send two notifications for the 933 event that the door bell was pressed: notification for changing from 934 unpressed to pressed and another one for changing back to unpressed. 935 If the time between the state changes is very short, the server might 936 drop the first notification, as Observe only guarantees only eventual 937 consistency (see Section 1.3 of [RFC7641]). 939 The solution is to pick a state model that fits better to the 940 application. In the case of the door bell - and many other event- 941 driven resources - the solution could be a counter that counts how 942 often the bell was pressed. The corresponding action is taken each 943 time the client observes a change in the received representation. 945 In the case of a network outage, this could lead to a ringing sound 946 10 minutes after the bell was rung. Also including a timestamp of 947 the last counter increment in the state can help to suppress ringing 948 a sound when the event has become obsolete. 950 6.3. Server Push 952 Overall, a universal mechanism for server push, that is, change-of- 953 state notifications and stand-alone event notifications, is still an 954 open issue that is being discussed in the Thing-to-Thing Research 955 Group. It is connected to the state-event duality problem and 956 custody transfer, that is, the transfer of the responsibility that a 957 message (e.g., event) is delivered successfully. 959 A proficient mechanism for change-of-state notifications is currently 960 only available for CoAP: Observing resources [RFC7641]. It offers 961 enventual consistency, which guarantees "that if the resource does 962 not undergo a new change in state, eventually all registered 963 observers will have a current representation of the latest resource 964 state". It intrinsically deals with the challenges of lossy 965 networks, where notifications might be lost, and constrained 966 networks, where there might not be enough bandwidth to propagate all 967 changes. 969 For stand-alone event notifications, that is, where every single 970 notification contains an identifiable event that must not be lost, 971 observing resources is not a good fit. A better strategy is to model 972 each event as a new resource, whose existence is notified through 973 change-of-state notifications of an index resource (cf. Collection 974 pattern). Large numbers of events will cause the notification to 975 grow large, as it needs to contain a large number of Web links. 976 Blockwise transfers [RFC7959] can help here. When the links are 977 ordered by freshness of the events, the first block can already 978 contain all links to new events. Then, observers do not need to 979 retrieve the remaining blocks from the server, but only the 980 representations of the new event resources. 982 An alternative pattern is to exploit the dual roles of IoT devices, 983 in particular when using CoAP: they are usually client and server at 984 the same time. A client observer would subscribe to events by 985 registering a callback URI at the origin server, e.g., using a POST 986 request and receiving the location of a temporary subscription 987 resource as handle. The origin server would then publish events by 988 sending POST requests containing the event to the observer. The 989 cancellation can be modeled through deleting the subscription 990 resource. This pattern makes the origin server responsible for 991 delivering the event notifications. This goes beyond retransmissions 992 of messages; the origin server is usually supposed to queue all 993 undelivered events and to retry until successful delivery or explicit 994 cancellation. In HTTP, this pattern is known as REST Hooks. 996 In HTTP, there exist a number of workarounds to enable server push, 997 e.g., long polling and streaming [RFC6202] or server-sent events 998 [W3C.REC-html5-20141028]. Long polling as an extension that both 999 server and client need to be aware of. In IoT systems, long polling 1000 can introduce a considerable overhead, as the request has to be 1001 repeated for each notification. Streaming and server-sent events (in 1002 fact an evolved version of streaming) are more efficient, as only one 1003 request is sent. However, there is only one response header and 1004 subsequent notifications can only have content. There are no means 1005 for individual status and metadata, and hence no means for proficient 1006 error handling (e.g., when the resource is deleted). 1008 7. Security Considerations 1010 This document does not define new functionality and therefore does 1011 not introduce new security concerns. We assume that system designers 1012 apply classic Web security on top of the basic RESTful guidance given 1013 in this document. Thus, security protocols and considerations from 1014 related specifications apply to RESTful IoT design. These include: 1016 o Transport Layer Security (TLS): [RFC5246] and [RFC6347] 1018 o Internet X.509 Public Key Infrastructure: [RFC5280] 1020 o HTTP security: Section 9 of [RFC7230], Section 9 of [RFC7231], 1021 etc. 1023 o CoAP security: Section 11 of [RFC7252] 1025 o URI security: Section 7 of [RFC3986] 1027 IoT-specific security is mainly work in progress at the time of 1028 writing. First specifications include: 1030 o (D)TLS Profiles for the Internet of Things: [RFC7925] 1031 Further IoT security considerations are available in 1032 [I-D.irtf-t2trg-iot-seccons]. 1034 8. Acknowledgement 1036 The authors would like to thank Mert Ocak, Heidi-Maria Back, Tero 1037 Kauppinen, Michael Koster, Robby Simpson, Ravi Subramaniam, Dave 1038 Thaler, Erik Wilde, and Niklas Widell for the reviews and feedback. 1040 9. References 1042 9.1. Normative References 1044 [I-D.ietf-core-object-security] 1045 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1046 "Object Security of CoAP (OSCOAP)", draft-ietf-core- 1047 object-security-04 (work in progress), July 2017. 1049 [I-D.ietf-core-resource-directory] 1050 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 1051 Amsuess, "CoRE Resource Directory", draft-ietf-core- 1052 resource-directory-11 (work in progress), July 2017. 1054 [REST] Fielding, R., "Architectural Styles and the Design of 1055 Network-based Software Architectures", Ph.D. Dissertation, 1056 University of California, Irvine , 2000. 1058 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1059 Resource Identifier (URI): Generic Syntax", STD 66, 1060 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1061 . 1063 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1064 (TLS) Protocol Version 1.2", RFC 5246, 1065 DOI 10.17487/RFC5246, August 2008, . 1068 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1069 Housley, R., and W. Polk, "Internet X.509 Public Key 1070 Infrastructure Certificate and Certificate Revocation List 1071 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1072 . 1074 [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem 1075 for the Simple Network Management Protocol (SNMP)", 1076 STD 78, RFC 5590, DOI 10.17487/RFC5590, June 2009, 1077 . 1079 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 1080 DOI 10.17487/RFC5988, October 2010, . 1083 [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, 1084 "Known Issues and Best Practices for the Use of Long 1085 Polling and Streaming in Bidirectional HTTP", RFC 6202, 1086 DOI 10.17487/RFC6202, April 2011, . 1089 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1090 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1091 January 2012, . 1093 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1094 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1095 . 1097 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1098 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1099 October 2013, . 1101 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1102 Protocol (HTTP/1.1): Message Syntax and Routing", 1103 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1104 . 1106 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1107 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1108 DOI 10.17487/RFC7231, June 2014, . 1111 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1112 Application Protocol (CoAP)", RFC 7641, 1113 DOI 10.17487/RFC7641, September 2015, . 1116 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1117 the Constrained Application Protocol (CoAP)", RFC 7959, 1118 DOI 10.17487/RFC7959, August 2016, . 1121 [W3C.REC-exi-20110310] 1122 Schneider, J. and T. Kamiya, "Efficient XML Interchange 1123 (EXI) Format 1.0", World Wide Web Consortium 1124 Recommendation REC-exi-20110310, March 2011, 1125 . 1127 [W3C.REC-html5-20141028] 1128 Hickson, I., Berjon, R., Faulkner, S., Leithead, T., 1129 Navara, E., O'Connor, T., and S. Pfeiffer, "HTML5", 1130 World Wide Web Consortium Recommendation REC- 1131 html5-20141028, October 2014, 1132 . 1134 9.2. Informative References 1136 [CollectionJSON] 1137 Amundsen, M., "Collection+JSON - Document Format", 1138 February 2013, 1139 . 1141 [I-D.ietf-core-coap-pubsub] 1142 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1143 Subscribe Broker for the Constrained Application Protocol 1144 (CoAP)", draft-ietf-core-coap-pubsub-02 (work in 1145 progress), July 2017. 1147 [I-D.ietf-core-senml] 1148 Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 1149 Bormann, "Media Types for Sensor Measurement Lists 1150 (SenML)", draft-ietf-core-senml-10 (work in progress), 1151 July 2017. 1153 [I-D.irtf-t2trg-iot-seccons] 1154 Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of- 1155 the-Art and Challenges for the Internet of Things 1156 Security", draft-irtf-t2trg-iot-seccons-05 (work in 1157 progress), September 2017. 1159 [IANA-CoAP-media] 1160 "CoAP Content-Formats", n.d., 1161 . 1164 [IANA-media-types] 1165 "Media Types", n.d., . 1168 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1169 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1170 . 1172 [RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for 1173 Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 1174 2013, . 1176 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1177 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1178 2014, . 1180 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1181 Constrained-Node Networks", RFC 7228, 1182 DOI 10.17487/RFC7228, May 2014, . 1185 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1186 Application Protocol (CoAP)", RFC 7252, 1187 DOI 10.17487/RFC7252, June 2014, . 1190 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, 1191 RFC 7320, DOI 10.17487/RFC7320, July 2014, 1192 . 1194 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 1195 Security (TLS) / Datagram Transport Layer Security (DTLS) 1196 Profiles for the Internet of Things", RFC 7925, 1197 DOI 10.17487/RFC7925, July 2016, . 1200 Appendix A. Future Work 1202 o Interface semantics: shared knowledge among system components (URI 1203 schemes, media types, relation types, well-known locations; see 1204 core-apps) 1206 o Unreliable (best effort) communication, robust communication in 1207 network with high packet loss, 3-way commit 1209 o Discuss directories, such as CoAP Resource Directory 1211 o More information on how to design resources; choosing what is 1212 modeled as a resource, etc. 1214 Authors' Addresses 1216 Ari Keranen 1217 Ericsson 1218 Jorvas 02420 1219 Finland 1221 Email: ari.keranen@ericsson.com 1222 Matthias Kovatsch 1223 ETH Zurich 1224 Universitaetstrasse 6 1225 Zurich CH-8092 1226 Switzerland 1228 Email: kovatsch@inf.ethz.ch 1230 Klaus Hartke 1231 Universitaet Bremen TZI 1232 Postfach 330440 1233 Bremen D-28359 1234 Germany 1236 Email: hartke@tzi.org