REST Without JSON: The Future of IoT Protocols

Originally published by Matt Butcher at https://dzone.com

With the rise of web-based APIs, we have come to think of REST (Representational State Transfer) as being synonymous with JSON over HTTP. Unsurprisingly, JSON has supplanted XML as the data format of choice for the web. While early IoT technologies have embraced the JSON/HTTP mix, that could soon be changing. The concept of REST will survive, but JSON and HTTP may not be the common language of IoT data interchange for much longer.

At its core, REST is an architectural pattern for uniformly accessing and modifying a resource. One entity (the server) is the authority over the current state of an object. Other entities may request a “representation” of the current object, and may also send requests to create, modify, or delete the object. The current popular REST model uses URIs to identify objects (“/lamp/1234”), HTTP verbs to specify an action, and JSON to represent the object. To fetch an object, a client may send an HTTP request to “GET /lamp/1234”. The server may respond with an HTTP 200 and a body containing JSON data.

The HTTP/JSON model is deeply entrenched in web APIs, and its popularity has naturally seeped into IoT technologies. Samsung, Nest, and Apple have all published APIs that rely on JSON over HTTP, but this early trend will wane. While the REST model works well for the distributed network that makes up the new IoT world, HTTP 1.1 and JSON are not the right fit.

What’s Wrong With JSON?

When JavaScript legend Douglas Crockford introduced the JSON format, he was interested in specifying a format that eased data interactions between web applications and JavaScript-based clients. Because it’s a lightweight alternative to XML, JSON quickly gained traction among web developers, and later reached a more general audience.

Several features of JSON make it a great candidate for general purpose data interchange. First, it is schemaless; as long as the JSON is well-formed, it is valid. Second, JSON supports a minimal and straightforward set of data types: strings, numbers, booleans, objects, arrays, and a null value. Third, the data is represented in JavaScript syntax, which makes it both human-readable and easily parseable. One would be hard-pressed to find a popular programming language that does not have at least one JSON parser.

These features make JSON a useful general-purpose format, but the typical use cases for IoT may cause us to doubt JSON’s appropriateness for the embedded systems that together make up the smart device landscape. IoT devices typically need to optimize along the following lines:

  • Keep network traffic small and fast.
  • Minimize the amount of raw computation for network encoding and decoding.
  • Use only small amounts of memory and storage.

Devices may run with less than a megabyte of memory or storage, and often run on small batteries. For power consumption reasons, they may only be on the Wi-Fi network for a few seconds at a time, and sometimes only a few times a day. Even high-end hub devices are unlikely to have more than 25MB of storage at their disposal. For these devices, efficiency is key, especially when it comes to networking.

JSON is not the best candidate for meeting these requirements. First, in spite of its claims to leanness, JSON is not a space-efficient encoding. All data are expressed as ASCII strings, often with copious white space added. Every label field must be repeated in its entirety for each occurrence. Binary data must be escaped, though there is no standard method for doing so in JSON.

This leads to a second issue with JSON. The simplicity of the data format introduces complexity in implementation. JSON’s simple types rarely match the types typically used in IoT programming. While languages like C support a broad array of numeric types, JSON’s only numeric type is number. The official JSON specification, ECMA-404, does not even define the maximum size of a number field. This means that a JSON consumer must do a fair amount of examination to determine which underlying type best matches a given number. This is complicated by the fact that two or more fields with the same apparent structure and field names may contain different “types” of numbers. The field “age” may in one occurrence be an unsigned positive integer and in another be a floating point.

The problem is compounded by JSON’s lack of schema. Arrays can contain any number of types, and there are no constraints on how the fields of an object are used or whether they are used consistently. Developers rely only on convention to determine what data a JSON structure will contain. Finally, there is the problem of interpreting a JSON data structure. Fields are essentially unordered (except for arrays). Valid JSON may, as noted above, contain arbitrary data that violates expectations, and it is up to the parser to solve any given data structure. Strategies used for efficient field-level processing generally don’t work well with JSON. Practically speaking, that means parsing an entire object and storing the results in memory.

JSON is clearly not the best technology for data encoding. HTTP 1.1, the other half of the ubiquitous REST implementation, does not come out looking much better.

What’s Wrong With HTTP?

HTTP 1.1 has served web developers well. It is flexible, straightforward, enjoys broad implementation, and has a huge developer base. But the HTTP faults that have irked web developers for years may have an even bigger impact on IoT developers.

Like JSON, HTTP tends toward the bloated side. HTTP headers are a good example. As plain text strings with no compression of any sort, they bloat the network protocol.

Network usage is another one of HTTP’s shortfalls. The original HTTP specification was designed around the idea of short-lived network connections. The client opens a connection and then requests a page, the server delivers it, and the connection is closed. But the average web page now may fetch over a dozen resources at once. HTTP 1.1 introduced some capabilities for keeping connections opened and reusable for short periods of time, but HTTP essentially remained focused on short-lived connections.

Consider the networking aspect of an IoT device. Establishing a connection is expensive in terms of power and time, especially with SSL/TLS negotiation included; every added connection brings along a substantial computational hit. Repeatedly opening heavyweight network connections is an unnecessary drain on resources.

In the IoT world, every byte sent and received from an embedded device takes its toll on performance. A good IoT protocol not only makes it easy for the developer to send the right information, but it also reduces the burden on the device and its network. The HTTP payload model is great for IoT, but a better protocol would streamline security, optimize transmission sizes, and focus on multiplexing requests and responses over long-lived network connections.

The Future Is Binary

REST is a good model for IoT. Each device can easily make its state information available and can standardize on a way to create, read, update, and delete that data. Developers can quickly build a mental REST model for many IoT devices. Get the state of the lightbulb: it is off. Send a request to turn it on. Get the current temperature from the space heater: it is too hot. Send a lower target temperature. The model seems to intuitively match the problem space.

But what is to be done about JSON and HTTP? IoT developers need REST without needless bloat.

For JSON, the future of IoT is bleak: a host of better-suited encodings are flooding the space. Apache Thrift and Google’s Protocol Buffers (Protobuf) each provide binary encodings better suited for constrained devices, and both have the advantage of automatically enforced schemas. CoAP, an emerging standard for IoT communication, defines an encoding called CBOR. CBOR is self-describing, and the encoding is focused on producing small message sizes. Even the venerable ASN.1 family of encodings may be getting a new IoT spin. All of these provide encoding characteristics better suited to embedded devices than JSON.

For HTTP, the story may play out differently. True, it will face some competition; for example, CoAP defines a concise REST-like transport protocol that is a compelling alternative to HTTP 1.1. But growing out of Google’s SPDY efforts, the HTTP/2 standard indicates that HTTP may have solved its own problems.

HTTP/2 shows a renewed interest in network performance. Headers in HTTP/2 are efficiently encoded. The protocol supports multiplexing many streams of data over one connection, as well as server-initiated pushes, and the reconstruction of the protocol maintains SSL/TLS as a central piece. One SSL/TLS negotiation can then protect multiple streams of data, thus reducing the setup overhead, but maintaining a high degree of security.

In addition to HTTP/2 and CoAP, the emerging QUIC protocol may also gain traction among resource-constrained devices. QUIC, also a Google protocol drawing from SPDY, trades TCP for UDP. By removing some of TCP’s connection management overhead, QUIC aims to reduce latency, particularly during initial establishment of a network connection.

Because QUIC and HTTP/2 are based on a similar protocol stack, the competition between the two is not a zero-sum game. Both are well-designed and are likely to gain acceptance in the emerging IoT space.

The Turning Tide

The REST model is a strong fit for IoT. However, the traditional REST implementation of JSON over HTTP is ill-fitting at best. JSON’s string-oriented payloads are no match for binary encodings when it comes to data transmission in terms of speed and ease of parsing. Encodings like CBOR and Protobuf are compelling alternatives to JSON.

In contrast, the HTTP/2 specification indicates that HTTP may remain the application protocol of choice. And its emerging sister protocol, QUIC, will complement and strengthen the position of web protocols in the IoT space.



#json #rest #web-development #javascript

What is GEEK

Buddha Community

REST Without JSON: The Future of IoT Protocols
Wilford  Pagac

Wilford Pagac

1596789120

Best Custom Web & Mobile App Development Company

Everything around us has become smart, like smart infrastructures, smart cities, autonomous vehicles, to name a few. The innovation of smart devices makes it possible to achieve these heights in science and technology. But, data is vulnerable, there is a risk of attack by cybercriminals. To get started, let’s know about IoT devices.

What are IoT devices?

The Internet Of Things(IoT) is a system that interrelates computer devices like sensors, software, and actuators, digital machines, etc. They are linked together with particular objects that work through the internet and transfer data over devices without humans interference.

Famous examples are Amazon Alexa, Apple SIRI, Interconnected baby monitors, video doorbells, and smart thermostats.

How could your IoT devices be vulnerable?

When technologies grow and evolve, risks are also on the high stakes. Ransomware attacks are on the continuous increase; securing data has become the top priority.

When you think your smart home won’t fudge a thing against cybercriminals, you should also know that they are vulnerable. When cybercriminals access our smart voice speakers like Amazon Alexa or Apple Siri, it becomes easy for them to steal your data.

Cybersecurity report 2020 says popular hacking forums expose 770 million email addresses and 21 million unique passwords, 620 million accounts have been compromised from 16 hacked websites.

The attacks are likely to increase every year. To help you secure your data of IoT devices, here are some best tips you can implement.

Tips to secure your IoT devices

1. Change Default Router Name

Your router has the default name of make and model. When we stick with the manufacturer name, attackers can quickly identify our make and model. So give the router name different from your addresses, without giving away personal information.

2. Know your connected network and connected devices

If your devices are connected to the internet, these connections are vulnerable to cyber attacks when your devices don’t have the proper security. Almost every web interface is equipped with multiple devices, so it’s hard to track the device. But, it’s crucial to stay aware of them.

3. Change default usernames and passwords

When we use the default usernames and passwords, it is attackable. Because the cybercriminals possibly know the default passwords come with IoT devices. So use strong passwords to access our IoT devices.

4. Manage strong, Unique passwords for your IoT devices and accounts

Use strong or unique passwords that are easily assumed, such as ‘123456’ or ‘password1234’ to protect your accounts. Give strong and complex passwords formed by combinations of alphabets, numeric, and not easily bypassed symbols.

Also, change passwords for multiple accounts and change them regularly to avoid attacks. We can also set several attempts to wrong passwords to set locking the account to safeguard from the hackers.

5. Do not use Public WI-FI Networks

Are you try to keep an eye on your IoT devices through your mobile devices in different locations. I recommend you not to use the public WI-FI network to access them. Because they are easily accessible through for everyone, you are still in a hurry to access, use VPN that gives them protection against cyber-attacks, giving them privacy and security features, for example, using Express VPN.

6. Establish firewalls to discover the vulnerabilities

There are software and firewalls like intrusion detection system/intrusion prevention system in the market. This will be useful to screen and analyze the wire traffic of a network. You can identify the security weakness by the firewall scanners within the network structure. Use these firewalls to get rid of unwanted security issues and vulnerabilities.

7. Reconfigure your device settings

Every smart device comes with the insecure default settings, and sometimes we are not able to change these default settings configurations. These conditions need to be assessed and need to reconfigure the default settings.

8. Authenticate the IoT applications

Nowadays, every smart app offers authentication to secure the accounts. There are many types of authentication methods like single-factor authentication, two-step authentication, and multi-factor authentication. Use any one of these to send a one time password (OTP) to verify the user who logs in the smart device to keep our accounts from falling into the wrong hands.

9. Update the device software up to date

Every smart device manufacturer releases updates to fix bugs in their software. These security patches help us to improve our protection of the device. Also, update the software on the smartphone, which we are used to monitoring the IoT devices to avoid vulnerabilities.

10. Track the smartphones and keep them safe

When we connect the smart home to the smartphone and control them via smartphone, you need to keep them safe. If you miss the phone almost, every personal information is at risk to the cybercriminals. But sometimes it happens by accident, makes sure that you can clear all the data remotely.

However, securing smart devices is essential in the world of data. There are still cybercriminals bypassing the securities. So make sure to do the safety measures to avoid our accounts falling out into the wrong hands. I hope these steps will help you all to secure your IoT devices.

If you have any, feel free to share them in the comments! I’d love to know them.

Are you looking for more? Subscribe to weekly newsletters that can help your stay updated IoT application developments.

#iot #enterprise iot security #how iot can be used to enhance security #how to improve iot security #how to protect iot devices from hackers #how to secure iot devices #iot security #iot security devices #iot security offerings #iot security technologies iot security plus #iot vulnerable devices #risk based iot security program

Wilford  Pagac

Wilford Pagac

1594289280

What is REST API? An Overview | Liquid Web

What is REST?

The REST acronym is defined as a “REpresentational State Transfer” and is designed to take advantage of existing HTTP protocols when used for Web APIs. It is very flexible in that it is not tied to resources or methods and has the ability to handle different calls and data formats. Because REST API is not constrained to an XML format like SOAP, it can return multiple other formats depending on what is needed. If a service adheres to this style, it is considered a “RESTful” application. REST allows components to access and manage functions within another application.

REST was initially defined in a dissertation by Roy Fielding’s twenty years ago. He proposed these standards as an alternative to SOAP (The Simple Object Access Protocol is a simple standard for accessing objects and exchanging structured messages within a distributed computing environment). REST (or RESTful) defines the general rules used to regulate the interactions between web apps utilizing the HTTP protocol for CRUD (create, retrieve, update, delete) operations.

What is an API?

An API (or Application Programming Interface) provides a method of interaction between two systems.

What is a RESTful API?

A RESTful API (or application program interface) uses HTTP requests to GET, PUT, POST, and DELETE data following the REST standards. This allows two pieces of software to communicate with each other. In essence, REST API is a set of remote calls using standard methods to return data in a specific format.

The systems that interact in this manner can be very different. Each app may use a unique programming language, operating system, database, etc. So, how do we create a system that can easily communicate and understand other apps?? This is where the Rest API is used as an interaction system.

When using a RESTful API, we should determine in advance what resources we want to expose to the outside world. Typically, the RESTful API service is implemented, keeping the following ideas in mind:

  • Format: There should be no restrictions on the data exchange format
  • Implementation: REST is based entirely on HTTP
  • Service Definition: Because REST is very flexible, API can be modified to ensure the application understands the request/response format.
  • The RESTful API focuses on resources and how efficiently you perform operations with it using HTTP.

The features of the REST API design style state:

  • Each entity must have a unique identifier.
  • Standard methods should be used to read and modify data.
  • It should provide support for different types of resources.
  • The interactions should be stateless.

For REST to fit this model, we must adhere to the following rules:

  • Client-Server Architecture: The interface is separate from the server-side data repository. This affords flexibility and the development of components independently of each other.
  • Detachment: The client connections are not stored on the server between requests.
  • Cacheability: It must be explicitly stated whether the client can store responses.
  • Multi-level: The API should work whether it interacts directly with a server or through an additional layer, like a load balancer.

#tutorials #api #application #application programming interface #crud #http #json #programming #protocols #representational state transfer #rest #rest api #rest api graphql #rest api json #rest api xml #restful #soap #xml #yaml

Joey  Grimes

Joey Grimes

1594207380

Understanding IoT Standards and Protocols | Powering Internet of Things

Introduction

A plethora of devices connected and sharing information is called the internet of things. These devices collect, send and receive data to applications, objects, and servers. They are used in various industries like automotive, industrial automation, medicine, security systems, and manufacturing.

There are various protocols and standards to connect. To decide a protocol, we need to consider the following aspects:

  • bandwidth
  • range
  • power consumptions
  • node of the protocols.

This article is aimed at understanding IoT standards and protocols offered by Internet Engineering Task Force (IETF), Institute of Electrical and Electronics Engineers (IEEE), and the International Telecommunication Union (ITU).

The following will give the protocol structure much better:

  • IoT Data Link Protocol
  • IEEE 802.15.4e
  • IEEE 802.11 ah
  • WirelessHART
  • Z-Wave
  • Bluetooth Low Energy
  • Zigbee Smart Energy
  • DASH7
  • HomePlug
  • G.9959
  • LTE-A
  • LoRaWAN
  • Weightless
  • DECT/ULE
  • Network Layer
  • Routing Protocols
  • RPL
  • CORPL
  • CARP
  • Encapsulation Protocols
  • LoWPAN
  • 6TiSCH
  • 6Lo
  • IPv6 over G.9959
  • IPv6 over Bluetooth Low Energy
  • Session Layer Protocols
  • MQTT
  • SMQTT
  • AMQP
  • CoAP
  • XMPP
  • DDS
  • IoT Management Protocol
  • Interconnection of Heterogeneous Datalink
  • Smart Transducer Interface
  • Security in IoT Protocols
  • MAC 802.15.4
  • 6LoWPAN
  • RPL
  • Application Layer

Background of IoT Protocol

In 1982, the first machine which can communicate, and track record was created. It was a soft drink vending machine from Coca-Cola. In 1999, an RFID technology researcher, Kelvin Ashton coined the term internet of things. In two decades from 2000-2019, the system had undergone rapid development and found many practical applications.

Since then, it has evolved as a different internet world, it requires a new range of standards and protocols. Although new standards are available some applications still use technology like HTTP.

Necessity of IoT Protocols

The following points will emphasize the necessity of these communication protocols and how they help us in overcoming issues:

  • Can be used to call for help in case of emergency or failure of another device which is connected.
  • Assist in notifying the user about the emergency.
  • Economically profitable, as the end-user data can be used to analyse trends and market.
  • Minimizes risks of security threats.
  • Unification of all the IoT communications available worldwide.
  • Heterogeneity within the connected systems.

Types of IoT Connections

The connections of the devices in IoT platform can be of following types:

  • Device to Device (D2D)
  • Device to Gateway
  • Gateway to Data systems
  • Between data systems

Let’s discuss in brief about each connection type of IoT.

#all #internet of things (iot) #iot development #iot standards #iot protocols #iot

Internet of Things (IoT): The Roadmap to a Smart Future - Mobinius

https://www.mobinius.com/blogs/internet-of-things-iot-the-roadmap-to-a-smart-future

#iot #iot-apps #iot-app-development-company #iot-solutions #hire-iot-developers #custom-iot-development

REST Without JSON: The Future of IoT Protocols

Originally published by Matt Butcher at https://dzone.com

With the rise of web-based APIs, we have come to think of REST (Representational State Transfer) as being synonymous with JSON over HTTP. Unsurprisingly, JSON has supplanted XML as the data format of choice for the web. While early IoT technologies have embraced the JSON/HTTP mix, that could soon be changing. The concept of REST will survive, but JSON and HTTP may not be the common language of IoT data interchange for much longer.

At its core, REST is an architectural pattern for uniformly accessing and modifying a resource. One entity (the server) is the authority over the current state of an object. Other entities may request a “representation” of the current object, and may also send requests to create, modify, or delete the object. The current popular REST model uses URIs to identify objects (“/lamp/1234”), HTTP verbs to specify an action, and JSON to represent the object. To fetch an object, a client may send an HTTP request to “GET /lamp/1234”. The server may respond with an HTTP 200 and a body containing JSON data.

The HTTP/JSON model is deeply entrenched in web APIs, and its popularity has naturally seeped into IoT technologies. Samsung, Nest, and Apple have all published APIs that rely on JSON over HTTP, but this early trend will wane. While the REST model works well for the distributed network that makes up the new IoT world, HTTP 1.1 and JSON are not the right fit.

What’s Wrong With JSON?

When JavaScript legend Douglas Crockford introduced the JSON format, he was interested in specifying a format that eased data interactions between web applications and JavaScript-based clients. Because it’s a lightweight alternative to XML, JSON quickly gained traction among web developers, and later reached a more general audience.

Several features of JSON make it a great candidate for general purpose data interchange. First, it is schemaless; as long as the JSON is well-formed, it is valid. Second, JSON supports a minimal and straightforward set of data types: strings, numbers, booleans, objects, arrays, and a null value. Third, the data is represented in JavaScript syntax, which makes it both human-readable and easily parseable. One would be hard-pressed to find a popular programming language that does not have at least one JSON parser.

These features make JSON a useful general-purpose format, but the typical use cases for IoT may cause us to doubt JSON’s appropriateness for the embedded systems that together make up the smart device landscape. IoT devices typically need to optimize along the following lines:

  • Keep network traffic small and fast.
  • Minimize the amount of raw computation for network encoding and decoding.
  • Use only small amounts of memory and storage.

Devices may run with less than a megabyte of memory or storage, and often run on small batteries. For power consumption reasons, they may only be on the Wi-Fi network for a few seconds at a time, and sometimes only a few times a day. Even high-end hub devices are unlikely to have more than 25MB of storage at their disposal. For these devices, efficiency is key, especially when it comes to networking.

JSON is not the best candidate for meeting these requirements. First, in spite of its claims to leanness, JSON is not a space-efficient encoding. All data are expressed as ASCII strings, often with copious white space added. Every label field must be repeated in its entirety for each occurrence. Binary data must be escaped, though there is no standard method for doing so in JSON.

This leads to a second issue with JSON. The simplicity of the data format introduces complexity in implementation. JSON’s simple types rarely match the types typically used in IoT programming. While languages like C support a broad array of numeric types, JSON’s only numeric type is number. The official JSON specification, ECMA-404, does not even define the maximum size of a number field. This means that a JSON consumer must do a fair amount of examination to determine which underlying type best matches a given number. This is complicated by the fact that two or more fields with the same apparent structure and field names may contain different “types” of numbers. The field “age” may in one occurrence be an unsigned positive integer and in another be a floating point.

The problem is compounded by JSON’s lack of schema. Arrays can contain any number of types, and there are no constraints on how the fields of an object are used or whether they are used consistently. Developers rely only on convention to determine what data a JSON structure will contain. Finally, there is the problem of interpreting a JSON data structure. Fields are essentially unordered (except for arrays). Valid JSON may, as noted above, contain arbitrary data that violates expectations, and it is up to the parser to solve any given data structure. Strategies used for efficient field-level processing generally don’t work well with JSON. Practically speaking, that means parsing an entire object and storing the results in memory.

JSON is clearly not the best technology for data encoding. HTTP 1.1, the other half of the ubiquitous REST implementation, does not come out looking much better.

What’s Wrong With HTTP?

HTTP 1.1 has served web developers well. It is flexible, straightforward, enjoys broad implementation, and has a huge developer base. But the HTTP faults that have irked web developers for years may have an even bigger impact on IoT developers.

Like JSON, HTTP tends toward the bloated side. HTTP headers are a good example. As plain text strings with no compression of any sort, they bloat the network protocol.

Network usage is another one of HTTP’s shortfalls. The original HTTP specification was designed around the idea of short-lived network connections. The client opens a connection and then requests a page, the server delivers it, and the connection is closed. But the average web page now may fetch over a dozen resources at once. HTTP 1.1 introduced some capabilities for keeping connections opened and reusable for short periods of time, but HTTP essentially remained focused on short-lived connections.

Consider the networking aspect of an IoT device. Establishing a connection is expensive in terms of power and time, especially with SSL/TLS negotiation included; every added connection brings along a substantial computational hit. Repeatedly opening heavyweight network connections is an unnecessary drain on resources.

In the IoT world, every byte sent and received from an embedded device takes its toll on performance. A good IoT protocol not only makes it easy for the developer to send the right information, but it also reduces the burden on the device and its network. The HTTP payload model is great for IoT, but a better protocol would streamline security, optimize transmission sizes, and focus on multiplexing requests and responses over long-lived network connections.

The Future Is Binary

REST is a good model for IoT. Each device can easily make its state information available and can standardize on a way to create, read, update, and delete that data. Developers can quickly build a mental REST model for many IoT devices. Get the state of the lightbulb: it is off. Send a request to turn it on. Get the current temperature from the space heater: it is too hot. Send a lower target temperature. The model seems to intuitively match the problem space.

But what is to be done about JSON and HTTP? IoT developers need REST without needless bloat.

For JSON, the future of IoT is bleak: a host of better-suited encodings are flooding the space. Apache Thrift and Google’s Protocol Buffers (Protobuf) each provide binary encodings better suited for constrained devices, and both have the advantage of automatically enforced schemas. CoAP, an emerging standard for IoT communication, defines an encoding called CBOR. CBOR is self-describing, and the encoding is focused on producing small message sizes. Even the venerable ASN.1 family of encodings may be getting a new IoT spin. All of these provide encoding characteristics better suited to embedded devices than JSON.

For HTTP, the story may play out differently. True, it will face some competition; for example, CoAP defines a concise REST-like transport protocol that is a compelling alternative to HTTP 1.1. But growing out of Google’s SPDY efforts, the HTTP/2 standard indicates that HTTP may have solved its own problems.

HTTP/2 shows a renewed interest in network performance. Headers in HTTP/2 are efficiently encoded. The protocol supports multiplexing many streams of data over one connection, as well as server-initiated pushes, and the reconstruction of the protocol maintains SSL/TLS as a central piece. One SSL/TLS negotiation can then protect multiple streams of data, thus reducing the setup overhead, but maintaining a high degree of security.

In addition to HTTP/2 and CoAP, the emerging QUIC protocol may also gain traction among resource-constrained devices. QUIC, also a Google protocol drawing from SPDY, trades TCP for UDP. By removing some of TCP’s connection management overhead, QUIC aims to reduce latency, particularly during initial establishment of a network connection.

Because QUIC and HTTP/2 are based on a similar protocol stack, the competition between the two is not a zero-sum game. Both are well-designed and are likely to gain acceptance in the emerging IoT space.

The Turning Tide

The REST model is a strong fit for IoT. However, the traditional REST implementation of JSON over HTTP is ill-fitting at best. JSON’s string-oriented payloads are no match for binary encodings when it comes to data transmission in terms of speed and ease of parsing. Encodings like CBOR and Protobuf are compelling alternatives to JSON.

In contrast, the HTTP/2 specification indicates that HTTP may remain the application protocol of choice. And its emerging sister protocol, QUIC, will complement and strengthen the position of web protocols in the IoT space.



#json #rest #web-development #javascript