RESTful Design for Internet of Things SystemsEricssonJorvas02420Finlandari.keranen@ericsson.comETH ZurichUniversitaetstrasse 6ZurichCH-8092Switzerlandkovatsch@inf.ethz.ch
T2TRG
This document gives guidance for designing Internet of Things (IoT)
systems that follow the principles of the Representational State
Transfer (REST) architectural style.The Representational State Transfer (REST) architectural style is a set of guidelines and best practices for building distributed hypermedia systems.
At its core is a set of constraints, which when fulfilled enable desirable properties for distributed software systems such as scalability and modifiability.
When REST principles are applied to the design of a system, the result is often called RESTful and in particular an API following these principles is called a RESTful API.Different protocols can be used with RESTful systems, but at the time of writing the most common protocols are HTTP and CoAP .
Since RESTful APIs are often simple and lightweight, they are a good fit for various IoT applications.
The goal of this document is to give basic guidance for designing RESTful systems and APIs for IoT applications and give pointers for more information.
Design of a good RESTful IoT system has naturally many commonalities with other Web systems.
Compared to other systems, the key characteristics of many IoT systems include:data formats, interaction patterns, and other mechanisms that minimize, or preferably avoid, the need for human interactionpreference for compact and simple data formats to facilitate efficient transfer over (often) constrained networks and lightweight processing in constrained nodesThis section explains some of the common terminology that is used in the context of RESTful design for IoT systems. For terminology of constrained nodes and networks, see .
A local store of response messages and the subsystem that controls storage, retrieval, and deletion of messages in it.
A node that sends requests to servers and receives responses.
The state kept by a client between requests. This typically includes the “current” resource, the set of active requests, the history of requests, bookmarks (URIs stored for later retrieval) and application-specific state. (Note that this is called “Application State” in , which has some ambiguity in modern (IoT) systems where the overall state of the distributed application (i.e., application state) is reflected in the union of all Client States and Resource States of all clients and servers involved.)
The practice of determining the “best” representation for a client when examining the current state of a resource. The most common forms of content negotiation are Proactive Content Negotiation and Reactive Content Negotiation.
A hypermedia control that enables a client to change the state of a resource or to construct a query locally.
An intermediary that is selected by a client, usually via local configuration rules, and that can be tasked to make requests on behalf of the client. This may be useful, for example, when the client lacks the capability to make the request itself or to service the response from a cache in order to reduce response time, network bandwidth and energy consumption.
A reverse proxy that provides an interface to a non-RESTful system such as legacy systems or alternative technologies such as Bluetooth ATT/GATT. See also “Reverse Proxy”.
A component embedded in a representation that identifies a resource for future hypermedia interactions, such as a link or a form. If the client engages in an interaction with the identified resource, the result may be a change to resource state and/or client state.
A method where multiple identical requests with that method lead to the same visible resource state as a single such request. For example, the PUT method replaces the state of a resource with a new state; replacing the state multiple times with the same new state still results in the same state for the resource. However, the response from the server can be different when the same idempotent method is used multiple times. For example when DELETE is used twice on an existing resource, the first request would remove the association and return success acknowledgement whereas the second request would likely result in error response due to non-existing resource.
A hypermedia control that enables a client to navigate between resources and thereby change the client state.
A string such as “text/html” or “application/json” that is used to label representations so that it is known how the representation should be interpreted and how it is encoded.
An operation associated with a resource. Common methods include GET, PUT, POST, and DELETE (see for details).
A server that is the definitive source for representations of its resources and the ultimate recipient of any request that intends to modify its resources. In contrast, intermediaries (such as proxies caching a representation) can assume the role of a server, but are not the source for representations as these are acquired from the origin server.
A content negotiation mechanism where the server selects a representation based on the expressed preference of the client. For example, in an IoT application, a client could send a request with preferred media type “application/senml+json”.
A content negotiation mechanism where the client selects a representation from a list of available representations. The list may, for example, be included by a server in an initial response. If the user agent is not satisfied by the initial response representation, it can request one or more of the alternative representations, selected based on metadata (e.g., available media types) included in the response.
A serialization that represents the current or intended state of a resource and that can be transferred between clients and servers. REST requires representations to be self-describing, meaning that there must be metadata that allows peers to understand which representation format is used. Depending on the protocol needs and capabilities, there can be additional metadata that is transmitted along with the representation.
A set of rules for serializing resource state. On the Web, the most prevalent representation format is HTML. Other common formats include plain text and formats based on JSON , XML, or RDF. Within IoT systems, often compact formats based on JSON, CBOR , and EXI are used.
An architectural style for Internet-scale distributed hypermedia systems.
An item of interest identified by a URI. Anything that can be named can be a resource. A resource often encapsulates a piece of state in a system. Typical resources in an IoT system can be, e.g., a sensor, the current value of a sensor, the location of a device, or the current state of an actuator.
A model of a resource’s possible states that is represented in a supported representation type, typically a media type. Resources can change state because of REST interactions with them, or they can change state for reasons outside of the REST model.
An intermediary that appears as a server towards the client but satisfies the requests by forwarding them to the actual server (possibly via one or more other intermediaries). A reverse proxy is often used to encapsulate legacy services, to improve server performance through caching, and to enable load balancing across multiple machines.
A method that does not result in any state change on the origin server when applied to a resource. For example, the GET method only returns a representation of the resource state but does not change the resource. Thus, it is always safe for a client to retrieve a representation without affecting server-side state.
A node that listens for requests, performs the requested operation and sends responses back to the clients.
A global identifier for resources. See for more details.The components of a RESTful system are assigned one or both of two roles: client or server.
Note that the terms “client” and “server” refer only to the roles that the nodes assume for a particular message exchange. The same node might act as a client in some communications and a server in others.
Classic user agents (e.g., Web browsers) are always in the client role and have the initiative to issue requests.
Origin servers always have the server role and govern over the resources they host.Intermediaries (such as forward proxies, reverse proxies, and gateways) implement both roles, but only forward requests to other intermediaries or origin servers.
They can also translate requests to different protocols, for instance, as CoAP-HTTP cross-proxies.Reverse proxies are usually imposed by the origin server.
In addition to the features of a forward proxy, they can also provide an interface for non-RESTful services such as legacy systems or alternative technologies such as Bluetooth ATT/GATT.
In this case, reverse proxies are usually called gateways.
This property is enabled by the Layered System constraint of REST, which says that a client cannot see beyond the server it is connected to (i.e., it is left unaware of the protocol/paradigm change).Nodes in IoT systems often implement both roles.
Unlike intermediaries, however, they can take the initiative as a client (e.g., to register with a directory, such as CoRE Resource Directory , or to interact with another thing) and act as origin server at the same time (e.g., to serve sensor values or provide an actuator interface).When designing a RESTful system, the state of the distributed application must be assigned to the different components.
Here, it is important to distinguish between “client state” and “resource state”.Client state encompasses the control flow and the interactions between the components (see ).
Following the Stateless constraint, the client state must be kept only on clients.
That is, there is no establishment of shared information about future interactions between client and server (usually called a session).
On the one hand, this makes requests a bit more verbose since every request must contain all the information necessary to process it.
On the other hand, this makes servers efficient and scalable, since they do not have to keep any state about their clients.
Requests can easily be distributed over multiple worker threads or server instances.
For the IoT systems, it lowers the memory requirements for server implementations, which is particularly important for constrained servers (e.g., sensor nodes) and servers serving large amount of clients (e.g., Resource Directory).Resource state includes the more persistent data of an application (i.e., independent of the client control flow and lifetime).
This can be static data such as device descriptions, persistent data such as system configuration, but also dynamic data such as the current value of a sensor on a thing.An important part of RESTful API design is to model the system as a set of resources whose state can be retrieved and/or modified and where resources can be potentially also created and/or deleted.Uniform Resource Identifiers (URIs) are used to indicate a resource for interaction, to reference a resource from another resource, to advertise or bookmark a resource, or to index a resource by search engines.A URI is a sequence of characters that matches the syntax defined in . It consists of a hierarchical sequence of five components: scheme, authority, path, query, and fragment (from most significant to least significant). A scheme creates a namespace for resources and defines how the following components identify a resource within that namespace. The authority identifies an entity that governs part of the namespace, such as the server “www.example.org” in the “http” scheme. A host name (e.g., a fully qualified domain name) or an IP address, potentially followed by a transport layer port number, are usually used in the authority component for the “http” and “coap” schemes. The path and query contain data to identify a resource within the scope of the URI’s scheme and naming authority. The fragment allows to refer to some portion of the resource, such as a section in an HTML document. However, fragments are processed only at client side and not sent on the wire. provides more details on URI design and ownership with best current practices for establishing URI structures, conventions, and formats.For RESTful IoT applications, typical schemes include “https”, “coaps”, “http”, and “coap”. These refer to HTTP and CoAP, with and without Transport Layer Security (TLS) . (CoAP uses Datagram TLS (DTLS) , the variant of TLS for UDP.) These four schemes also provide means for locating the resource; using the HTTP protocol for “http” and “https”, and with the CoAP protocol for “coap” and “coaps”. If the scheme is different for two URIs (e.g., “coap” vs. “coaps”), it is important to note that even if the rest of the URI is identical, these are two different resources, in two distinct namespaces.The query parameters can be used to parametrize the resource. For example, a GET request may use query parameters to request the server to send only certain kind data of the resource (i.e., filtering the response). Query parameters in PUT and POST requests do not have such established semantics and are not commonly used.
Whether the order of the query parameters matters in URIs is unspecified and they can be re-ordered e.g., by proxies. Therefore applications should not rely on their order; see Section 3.3 of for more details.Clients can retrieve the resource state from an origin server or manipulate resource state on the origin server by transferring resource representations.
Resource representations have a media type that tells how the representation should be interpreted by identifying the representation format used.
Typical media types for IoT systems include “text/plain” for simple UTF-8 text, “application/octet-stream” for arbitrary binary data, “application/json” for the JSON format , “application/senml+json” for Sensor Markup Language (SenML) formatted data, “application/cbor” for CBOR , and “application/exi” for EXI .
A full list of registered Internet Media Types is available at the IANA registry and numerical media types registered for use with CoAP are listed at CoAP Content-Formats IANA registry .Section 4.3 of defines the set of methods in HTTP;
Section 5.8 of defines the set of methods in CoAP.
As part of the Uniform Interface constraint, each method can have certain properties that give guarantees to clients:
Safe methods do not cause any state change on the origin server when applied to a resource.
Idempotent methods can be applied multiple times to the same resource while causing the same visible resource state as a single such request.
The following lists the most relevant methods and gives a short explanation of their semantics.The GET method requests a current representation for the target resource.
Only the origin server needs to know how each of its resource identifiers corresponds to an implementation and how each implementation manages to select and send a current representation of the target resource in a response to GET.A payload within a GET request message has no defined semantics.The GET method is safe and idempotent.The POST method requests that the target resource process the representation enclosed in the request according to the resource’s own specific semantics.If one or more resources has been created on the origin server as a result of successfully processing a POST request, the origin server sends a 201 (Created) response containing a Location header field that provides an identifier for the resource created and a representation that describes the status of the request while referring to the new resource(s).The POST method is not safe nor idempotent.The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload.
A successful PUT of a given representation would suggest that a subsequent GET on that same target resource will result in an equivalent representation being sent.The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation.
The target resource in a POST request is intended to handle the enclosed representation according to the resource’s own semantics, whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource.
Hence, the intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server.The PUT method is not safe, but is idempotent.The DELETE method requests that the origin server remove the association between the target resource and its current functionality.If the target resource has one or more current representations, they might or might not be destroyed by the origin server, and the associated storage might or might not be reclaimed, depending entirely on the nature of the resource and its implementation by the origin server.The DELETE method is not safe, but is idempotent.Section 6 of defines a set of Status Codes in HTTP that are used by application to indicate whether a request was understood and satisfied, and how to interpret the answer.
Similarly, Section 5.9 of defines the set of Response Codes in CoAP.The status codes consist of three digits (e.g., “404” with HTTP or “4.04” with CoAP) where the first digit expresses the class of the code.
Implementations do not need to understand all status codes, but the class of the code must be understood.
Codes starting with 1 are informational; the request was received and being processed.
Codes starting with 2 indicate a successful request.
Codes starting with 3 indicate redirection; further action is needed to complete the request.
Codes stating with 4 and 5 indicate errors.
The codes starting with 4 mean client error (e.g., bad syntax in the request) whereas codes starting with 5 mean server error; there was no apparent problem with the request, but server was not able to fulfill the request.Responses may be stored in a cache to satisfy future, equivalent requests.
HTTP and CoAP use two different patterns to decide what responses are cacheable.
In HTTP, the cacheability of a response depends on the request method (e.g., responses returned in reply to a GET request are cacheable).
In CoAP, the cacheability of a response depends on the response code (e.g., responses with code 2.04 are cacheable).
This difference also leads to slightly different semantics for the codes starting with 2; for example, CoAP does not have a 2.00 response code whereas 200 (“OK”) is commonly used with HTTP.The REST architectural style defines a set of constraints for the system design.
When all constraints are applied correctly, REST enables architectural properties of key interest :PerformanceScalabilityReliabilitySimplicityModifiabilityVisibilityPortabilityThe following sub-sections briefly summarize the REST constraints and explain how they enable the listed properties.As explained in the Architecture section, RESTful system components have clear roles in every interaction.
Clients have the initiative to issue requests, intermediaries can only forward requests, and servers respond requests, while origin servers are the ultimate recipient of requests that intent to modify resource state.This improves simplicity and visibility, as it is clear which component started an interaction.
Furthermore, it improves modifiability through a clear separation of concerns.The Stateless constraint requires messages to be self-contained.
They must contain all the information to process it, independent from previous messages.
This allows to strictly separate the client state from the resource state.This improves scalability and reliability, since servers or worker threads can be replicated.
It also improves visibility because message traces contain all the information to understand the logged interactions.Furthermore, the Stateless constraint enables caching.This constraint requires responses to have implicit or explicit cache-control metadata.
This enables clients and intermediary to store responses and re-use them to locally answer future requests.
The cache-control metadata is necessary to decide whether the information in the cached response is still fresh or stale and needs to be discarded.Cache improves performance, as less data needs to be transferred and response times can be reduced significantly.
Less transfers also improves scalability, as origin servers can be protected from too many requests.
Local caches furthermore improve reliability, since requests can be answered even if the origin server is temporarily not available.RESTful APIs all use the same interface independent of the application.
It is defined by:URIs to identify resourcesrepresentation formats to retrieve and manipulate resource stateself-descriptive messages with a standard set of methods (e.g., GET, POST, PUT, DELETE with their guaranteed properties)hypermedia controls within representationsThe concept of hypermedia controls is also known as HATEOAS: hypermedia as the engine of application state.
The origin server embeds controls for the interface into its representations and thereby informs the client about possible requests.
The mostly used control for RESTful systems is Web Linking .
Hypermedia forms are more powerful controls that describe how to construct more complex requests, including representations to modify resource state.While this is the most complex constraints (in particular the hypermedia controls), it improves many different key properties.
It improves simplicity, as uniform interfaces are easier to understand.
The self-descriptive messages improve visibility.
The limitation to a known set of representation formats fosters portability.
Most of all, however, this constraint is the key to modifiability, as hypermedia-driven, uniform interfaces allow clients and servers to evolve independently, and hence enable a system to evolve.This constraint enforces that a client cannot see beyond the server with which it is interacting.A layered system is easier to modify, as topology changes become transparent.
Furthermore, this helps scalability, as intermediaries such as load balancers can be introduced without changing the client side.
The clean separation of concerns helps with simplicity.This principle enables origin servers to ship code to clients.Code-on-Demand improves modifiability, since new features can be deployed during runtime (e.g., support for a new representation format).
It also improves performance, as the server can provide code for local pre-processing before transferring the data.This document does not define new functionality and therefore does not introduce new security concerns.
We assume that system designers apply classic Web security on top of the basic RESTful guidance given in this document.
Thus, security protocols and considerations from related specifications apply to RESTful IoT design.
These include:Transport Layer Security (TLS): and Internet X.509 Public Key Infrastructure: HTTP security: Section 9 of , Section 9 of , etc.CoAP security: Section 11 of URI security: Section 7 of IoT-specific security is mainly work in progress at the time of writing.
First specifications include:(D)TLS Profiles for the Internet of Things: The authors would like to thank Mert Ocak, Heidi-Maria Back, Tero Kauppinen, Michael Koster, Robby Simpson, Ravi Subramaniam, Dave Thaler, and Erik Wilde for the reviews and feedback.Uniform Resource Identifier (URI): Generic SyntaxA Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and RoutingThe Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.Hypertext Transfer Protocol (HTTP/1.1): Semantics and ContentThe Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.Architectural Styles and the Design of Network-based Software ArchitecturesThe Transport Layer Security (TLS) Protocol Version 1.2This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]Datagram Transport Layer Security Version 1.2This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]CoRE Resource DirectoryIn many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources. This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to register, maintain, lookup and remove resource descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined.Concise Binary Object Representation (CBOR)The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.Efficient XML Interchange (EXI) Format 1.0Transport Subsystem for the Simple Network Management Protocol (SNMP)This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models that is comparable to other subsystems in the RFC 3411 architecture. As work is being done to expand the transports to include secure transports, such as the Secure Shell (SSH) Protocol and Transport Layer Security (TLS), using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. [STANDARDS-TRACK]Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileThis memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]Object Security of CoAP (OSCOAP)This document defines Object Security of CoAP (OSCOAP), a method for application layer protection of the Constrained Application Protocol (CoAP), using the CBOR Object Signing and Encryption (COSE). OSCOAP provides end-to-end encryption, integrity and replay protection to CoAP payload, options, and header fields, as well as a secure message binding. OSCOAP is designed for constrained nodes and networks and can be used across intermediaries and over any layer. The use of OSCOAP is signaled with the CoAP option Object-Security, also defined in this document.Terminology for Constrained-Node NetworksThe Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.The Constrained Application Protocol (CoAP)The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.The JavaScript Object Notation (JSON) Data Interchange FormatJavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of ThingsA common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments.This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols.Media Types for Sensor Measurement Lists (SenML)This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), eXtensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use this media type in protocols such as HTTP or CoAP to transport the measurements of the sensor or to be configured.Media TypesCoAP Content-FormatsURI Design and OwnershipSection 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme." In other words, the structure of a URI is defined by its scheme. While it is common for schemes to further delegate their substructure to the URI's owner, publishing independent standards that mandate particular forms of URI substructure is inappropriate, because that essentially usurps ownership. This document further describes this problematic practice and provides some acceptable alternatives for use in standards.Issues in Identifier Comparison for Security PurposesIdentifiers such as hostnames, URIs, IP addresses, and email addresses are often used in security contexts to identify security principals and resources. In such contexts, an identifier presented via some protocol is often compared using some policy to make security decisions such as whether the security principal may access the resource, what level of authentication or encryption is required, etc. If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result. This document provides a discussion of these issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols.Interface semantics: shared knowledge among system components (URI schemes, media types, relation types, well-known locations; see core-apps)Discuss design patterns, such as “Observing state (asynchronous updates) of a resource”, “Executing a Function”, “Events as State”, “Conversion”, “Collections”, “robust communication in network with high packet loss”, “unreliable (best effort) communication”, “3-way commit”, etc.Discuss directories, such as CoAP Resource DirectoryMore information on how to design resources; choosing what is modeled as a resource, etc.