IoT Is Eating the World: APIs and REST
IoT is eating the world. In this installment, we check out APIs and the REST architecture and how they are impacting the future of IoT.
Join the DZone community and get the full member experience.
Join For FreeConsidering that 80 percent of devices will be IoT devices, IoT has the greatest potential to advance society — a world where all kinds of devices are interconnected and smart, communicating and improving our quality of life. But why is it that IoT still feels shallow, consumeristic, and only focused on “1st world” gadgets that are more of a nice to have? Just as software has transformed industries, I now believe that IoT is eating the world through data-spouting devices connected to the Internet. Here, everything gets connected. We are currently in a growth spurt: the migration of analog functions monitoring and managing the physical world to digital functions involving communications and software.
With IoT, we are basically exposing a new platform. Here’s an analogy: before smartphones, regular phones had sensors, speakers, mics, and GPS — yet no one did anything but speak. Then, we put an operating system on top of the same hardware. Now the hardware functionality is exposed as a set of APIs where devs can do what they want. We exposed a new platform, and IoT is doing the same thing.
Why Are APIs Linked With IoT?
An API is a set of routines, protocols, and tools for building software applications; it specifies how software components should interact. APIs are tightly linked with IoT because they allow you to securely expose connected devices to customers, go-to-market channels, and other applications in your IT infrastructure. Because APIs connect important “things,” like cars, medical devices, smart grids, and thermostats, to your ecosystem, it’s critical to deploy API management that is flexible, scalable, and secure.
APIs provide the ability to glue and integrate services, leaving devs to focus on application interaction vs. the applications themselves. APIs allow developers to build context-based applications that can interact with the physical world, instead of purely through UI (proximity and location-aware). To truly achieve IoT, we need a REST API for every device. REST allows data to flow over Internet protocols and to delegate and manage authorization.
APIs can be external services requiring a “key” for use, or they can be 100 percent free and publicly available, not requiring registration with the originating entity. With the help of APIs, a single app can utilize software written with multiple programming languages — thanks to a unified architectural style called REST. IoT means we’re building more apps, so no matter where you go in the IoT, you’re bound to need RESTful services.
Unstructured data goes to object storage, semi-structure goes to MongoDB, Cassandra, traditional, and transactional data goes to SQL, MySQL, and so on. As a developer, it’s challenging to deal with proprietary APIs exposed by these data sources. To integrate one unstructured, one semi-structured, and one structured database in your app, you have to deal with at least three proprietary APIs. This doesn’t make you as productive, and the code is more prone to errors because you are mixing and matching highly heterogeneous APIs into your applications.
No lane dividers, signals or crosswalks before the Industrial Revolution.
Imagine driving through dense city traffic using roads without any lane dividers, crosswalks, or signals. It would be utter chaos. That is the reality of the current state of the IoT. There is a lack of holistic information design. We must standardize the flow of information to allow true machine-to-machine connectivity to arise, and thankfully, this can be achieved using APIs — REST APIs to be specific. Populating urban environments with innovative machine-to-machine connections is the future of the IoT.
When plotting connections within the IoT, nodes are devices and arcs are APIs. Indeed, to fully realize the benefits IoT has to offer, OT assets will need to be designed with web technologies built directly into them, such as HTTP for interaction, SSL/ TLS encryption and authentication for data security, and JSON for data format. This approach is available today through a RESTful architecture.
REST: a Developers Best Friend
REST (I didn’t think you had enough acronyms to remember yet) stands for Representational State Transfer, and it is a concept, not a protocol. But it is the basis of the most widely used form of API today. RESTful APIs are widely used in the modern web, and data transfer usually takes place using JSON or XML over HTTP. REST is a stateless concept — e.g. the client will connect and consume the API on demand, passing any data that is relevant to the request at the time of use. It does not maintain a constantly open connection, so it is very scalable.
Apps that are RESTful are those whose APIs follow a universal set of architectural requirements so that multiple programming languages can easily plugin to an API in a unified approach. REST is recourse-based, instead of action-based, like SOAP.
REST APIs typically use methods of the HTTP specification to perform different actions. For example — POST, GET, PUT, and DELETE can be logically mapped to SQL CREATE, SELECT (READ), UPDATE, and DELETE, functions. This is known as CRUD, and it means that everything you might want to do to a piece of data stored on a remote server can be done predictably through a REST API.
REST plays a crucial role, and you can use REST across the stack. REST has become a de facto protocol for the web and is understood by almost every web server, endpoint, and server that is out there on the Internet. IoT leverages a lot of REST end points. Of course, there are other protocols like MQTT, but it’s not very mature and is still evolving. Lot’s of services rely on REST, and it allows you to quickly wire up IoT as the glue that brings multiple services together.
A certainty about the Internet of Things is, well, the Internet. The near-universal way applications and devices communicate over the Internet are via RESTful services. REST APIs provide the simplest way for connected applications and “Things” to interact in a standard, well-understood way. Plus, the data from all these connected things needs to be ingested, stored, and processed in a variety of database types, and consistent REST APIs is the most efficient way to do it.
REST addresses the following:
- Performance
- Scalability
- Simplicity of interfaces
- Modifiability
- Visibility
- Portability
- Reliability
As it uses HTTP, any device that can connect to the web and request a web page can use a REST API. REST is a good model for IoT, because each device can easily make its state information available and can standardize the way to create, read, update, and delete that data. Developers can quickly build a REST model for many IoT devices. You can then, for example, easily get the state of the lightbulb: it is off. Then, you can send a request to turn it on. Get the current temperature from the space heater; it is too hot. Then, you can send a lower target temperature. This model intuitively matches the problem space.
What it Takes to Develop for IoT
The real trick in an Internet of Things product is moving data in an efficient and fast way — so, at the heart of any IoT implementation, is the API. Done correctly, it can simplify your code, speed up development, and if you ultimately deliver data seamlessly to the user, it can actually enhance your user’s experience. You can think of the API as the product, and the developer is the customer.
Device people and software people don’t understand each other. For the device folks, the API is the product and the app developers are the primary consumers. When building APIs for devices, you need to understand the needs of the consumers in terms of design and the preferred protocols that mimic present web architecture.
REST and JSON APIs enable software engineers to never reinvent the wheel when building new apps. REST is the architecture of the web, and if you’re going to be building applications on the web — shouldn’t you work with the architecture not against it?
Making it easier for software developers to work with connected things without needing to know its intricacies or protocol will make the IoT more accessible to developers. APIs solve this challenge beautifully because they abstract the thing and expose it as an interface, enabling developers to program devices just like they work with existing backend systems when building mobile apps. To a software developer, turning on a light bulb now looks exactly like adding data to an SAP system. The API Layer is leveraged by IoT architecture to connect to the server layer. This provides consistency, control, governance, security, and an analytics-based model for connecting external sites.
Abundance author Peter Diamandis and Steven Kotler say that this mobile development is most important among the “rising bottom billion,” and it is these individuals who can experience the greatest amount of poverty-reduction with the introduction of new technology and education through software.
For the first time ever, the rising billion will have the remarkable power to identify, solve, and implement their own abundance solutions.”
In July 2015, Sam Macklin of CA Technologies and the API Academy notes:
“In the future, every successful company will be a software company and every successful software company will be an API provider.”
We are in an exciting time and witnessing the growth of businesses and solutions thanks to high-quality software with APIs. Humanity is facing an app-driven future where more jobs for coders and non-coders alike will be available than people to fill them.
We are at the beginning of IoT adoption. So NOW is the best time to start considering IoT for your projects. There’s a lot of excitement and potential to converge data that have never met each other before, as well as development opportunities on the device side and the application side. The future focus will be on connecting devices, software and, people. Stay tuned!
Opinions expressed by DZone contributors are their own.
Comments