Lecture 12
Download as PPTX, PDF•0 likes•64 views
The document discusses designing Internet of Things (IoT) systems following the Representational State Transfer (REST) architectural style. It describes REST as defining a set of constraints for building distributed hypermedia systems, including uniform interfaces using HTTP/CoAP methods, a client-server architecture, and stateless operations. Applying these constraints in IoT system design enables properties like performance, scalability, reliability and simplicity.
Lecture 12
- 1. Vishal Choudhary [email protected] REST-Design for Internet of Things Systems
- 7. 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 REST and in particular an API following these principles is called a REST API.
- 8. Representational state transfer (REST) is a software architectural style that defines a set of constraints to be used for creating Web services. Web services that conform to the REST architectural style, called RESTful Web services, provide interoperability between computer systems on the internet.
- 9. Architectural properties Performance in component interactions, which can be the dominant factor in user-perceived performance and network efficiency Scalability allowing the support of large numbers of components and interactions among components. Simplicity of a uniform interface; Modifiability of components to meet changing needs (even while the application is running); Visibility of communication between components by service agents; Portability of components by moving program code with the data; Reliability in the resistance to failure at the system level in the presence of failures within components, connectors, or
- 10. Most common protocols are HTTP and CoAP REST APIs are often simple and lightweight, they are a good fit for various IoT applications. the key characteristics of many IoT systems include: data formats, interaction patterns, and other mechanisms that minimize, or preferably avoid, the need for human interaction preference for compact and simple data formats to facilitate efficient transfer over (often) constrained networks and lightweight processing in constrained nodes
- 11. Architecture 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.
- 12. 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. Communication with Forward Proxy
- 13. 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. 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). Communication with Reverse Proxy
- 14. System design When designing a RESTful system, the primary effort goes into modeling the state of the distributed application and assigning it to the different components (i.e., clients and servers). How clients can navigate through the resources and modify state to achieve their goals is defined through hypermedia controls, that is, links and forms. Hypermedia controls span a kind of a state machine where the nodes are resources and the transitions are links or forms. Clients run this state machine (i.e., the application) by retrieving representations, processing the data, and following the included hypermedia controls. In REST, remote state is changed by submitting forms. This is usually done by retrieving the current state, modifying the state on the client side, and transferring the new state to the server in the form of new representations – rather than calling a service and modifying the state on the server side.
- 15. HTTP/CoAP Methods 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. 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. Idempotent methods can be applied multiple times to the same resource while causing 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. The following lists the most relevant methods and gives a short
- 16. GET The GET method requests a current representation for the target resource, while the origin server must ensure that there are no side-effects on the resource state. 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.
- 17. POST 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 response containing a Location header field (with HTTP) or Location-Path and/or Location-Query Options (with CoAP) that provide an identifier for the resource created. The server also includes a representation that describes the status of the request while referring to the new resource(s).
- 18. PUT 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
- 19. DELETE 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.
- 20. REST Constraints 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 Performance Scalability Reliability Simplicity Modifiability Visibility Portability
- 21. Client-Server 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 following sub-sections briefly summarize the REST constraints and explain how they enable the listed properties.
- 22. Stateless 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.
- 23. Cache 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.
- 24. Uniform Interface All RESTful APIs use the same, uniform interface independent of the application. This simple interaction model is enabled by exchanging representations and modifying state locally, which simplifies the interface between clients and servers to a small set of methods to retrieve, update, and delete state – which applies to all applications. In contrast, in a service-oriented RPC approach, all required ways to modify state need to be modeled explicitly in the interface resulting in a large set of methods – which differs from application to application. Moreover, it is also likely that different parties come up with different ways how to modify state, including the naming of the procedures, while the state within an application is a bit easier to agree on. A REST interface is fully defined by: URIs to identify resources representation formats to represent (and retrieve and manipulate) resource state self-descriptive messages with a standard set of methods (e.g., GET, POST, PUT, DELETE with their guaranteed properties) hypermedia controls within representation
- 25. Layered System 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.
- 26. Code-on-Demand 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.
- 27. Representational State Transfer (REST) Representational State Transfer (REST) is a style of architecture based on a set of principles that describe how networked resources are defined and addressed. These principles were first described in 2000 by Roy Fielding as part of his doctoral dissertation. REST is an alternative to SOAP and JavaScript Object Notation (JSON). It is important to note that REST is a style of software architecture as opposed to a set of standards. As a result, such applications or architectures are sometimes referred to as RESTful or REST-style applications or architectures. REST has proved to be a popular choice for implementing Web Services. For example, the books suggested at the bottom of many of these article pages are dynamically generated, in part, using a REST architecture.
- 28. An application or architecture considered RESTful or REST-style is characterized by: State and functionality are divided into distributed resources Every resource is uniquely addressable using a uniform and minimal set of commands (typically using HTTP commands of GET, POST, PUT, or DELETE over the Internet) The protocol is client/server, stateless, layered, and supports caching
- 29. Constrained Application Protocol Constrained Application Protocol (CoAP) is a specialized Internet Application Protocol for constrained devices,. It enables those constrained devices called "nodes" to communicate with the wider Internet using similar protocols. CoAP is designed for use between devices on the same constrained network (e.g., low-power, lossy networks), between devices and general nodes on the Internet, and between devices on different constrained networks both joined by an internet. CoAP is also being used via other mechanisms, such as SMS on mobile communication networks. CoAP is a service layer protocol that is intended for use in resource-constrained internet devices, such as wireless sensor network nodes. CoAP is designed to easily translate to HTTP for simplified integration
- 30. CoAP Many services to many things For internet we used web But for low power device(constraints) We use COAP which can work on low power low bandwidth application Its very compact 4 byte header Strong inbuilt security Asynchronous subscription
- 40. MQTT MQTT (MQ Telemetry Transport) is a lightweight messaging protocol that provides resource-constrained network clients with a simple way to distribute telemetry information. The protocol, which uses a publish/subscribe communication pattern, is used for machine-to-machine (M2M) communication and plays an important role in the internet of things (IoT). the TT in MQTT stands for Telemetry Transport, the MQ is
- 41. The MQTT protocol surrounds two subjects: a client and a broker. An MQTT broker is a server, while the clients are the connected devices. When a device -- or client -- wants to send data to a server -- or broker-- it is called a publish. When the operation is reversed, it is called a subscribe. If the connection from a subscribing client to a broker is broken, then the broker will buffer messages and push them out to the subscriber when it is back online. If the connection from the publishing client to the broker is disconnected without notice, then the broker can close the connection and send subscribers a cached message with instructions from the publisher.
- 42. How MQTT works An MQTT session is divided into four stages: connection, authentication, communication and termination. A client starts by creating a Transmission Control Protocol/Internet Protocol (TCP/IP) connection to the broker by using either a standard port or a custom port defined by the broker's operators. When creating the connection, it is important to recognize that the server might continue an old session if it is provided with a reused client identity.
- 43. the MQTT protocol aims to be a protocol for resource- constrained and IoT devices, SSL/TLS might not always be an option and, in some cases, might not be desired. On such occasions, authentication is presented as a cleartext username and password, which are sent by the client to the server -- this, as part of the CONNECT/CONNACK packet sequence. In addition, some brokers, especially open brokers published on the internet, will accept anonymous clients. In such cases, the username and
- 44. MQTT is called a lightweight protocol because all its messages have a small code footprint. Each message consists of a fixed header -- 2 bytes -- an optional variable header, a message payload that is limited to 256 megabytes (MB) of information and a quality of service (QoS) level. During the communication phase, a client can perform publish, subscribe, unsubscribe and ping operations. The publish operation sends a binary block of data -- the content -- to a topic that is defined by the
- 45. MQTT is one of the most commonly used protocols concerning IoT. MQTT enables resource-constrained IoT devices to send, or publish, information about a given topic to a server that functions as an MQTT message broker. The broker then pushes the information out to those clients that have previously subscribed to the topic. To a human, a topic looks like a hierarchical file path. Clients can subscribe to a specific level of a topic's hierarchy or use a wild-card character to subscribe to
- 46. MQTT has a few distinct advantages and disadvantages when compared to competing protocols. Advantages include the following: efficient data transmission and quick to implement due to its being a lightweight protocol; low network usage, due to minimized data packets; efficient distribution of data; successful implementation of remote sensing and control; fast and efficient message delivery; usage of small amounts of power, which is good for the connected devices; and reduction of network bandwidth
- 47. disadvantages MQTT has slower transmit cycles compared to CoAP. MQTT's resource discovery works on flexible topic subscription, whereas CoAP uses a stable resource discovery system. MQTT is unencrypted. Instead, it uses TLS/SSL for security encryption. It is difficult to create a globally scalable MQTT network.