Why Use ASP.NET Web API for IoT?

This guide is for you, if you are:

1. An IoT developer or work with IoT folks to provide communication support for the connected devices
2. Interested in building web services for devices
3. An ASP.NET developer
4. Anyone else who wants to build a native HTTP web service

My goal in this guide is to convince you to at least consider using ASP.NET Web API as the main framework for programming web services for the IoT-connected devices.

Some people may believe that IoT is something new and special, but this notion is incorrect. IoT devices have been the same embedded devices, mobile devices, and other desktop applications that we've seen for many years. Yet, currently they are more powerful. They provide more features but there is no new science behind them.

A few years ago, we witnessed a significant shift in technology: everything began requiring a network connection to work in the server-client architecture.

In this guide, my focus is on delivering user data on the IoT devices and teaching numerous other pertinent factors of web-based IoT programming. But first, let's dig deeper and understand what made the network connected device communication so important to everyday life.

The factors that make network requirement a must-have are the factors that can improve security of your application, performance of your applications, decrease the memory requirements on the devices, and much more.

Besides the usages, it is also better to consider using a better framework for building the web services. I have been told many times that IoT requires a lot of considerations, that IoT is tough, and so on. But the thing is, it is the same framework as embedded computing was. In the old days, the framework was not given a particular name, so programmers called these systems Embedded Systems. Recently, programmers have stopped calling them Embedded Systems, opting for the IoT label instead.

In my own experience, I have found that building an ASP.NET Web API is very helpful and straightforward when compared to building the WCF (Windows Communications Foundation) applications and web services for the connectivity of the devices.

Web services (or the server-client framework) should be considered because they require marginal programming. Furthermore, in case of any trouble, your clients don't have to come to you and get the devices fixed. Web services allow customers to take advantage of quick access, using the worldwide web.

Some other advantages of embedded web services:

1. All of the source code remains on your hand
2. You can fix, monitor, update, and publish new features as they come live from your development teams
3. Clients' devices don't stay broken if there is a problem
4. Devices with few hardware resources can also work because most of the processing is done on the server
5. Anyone can connect to these services

There are countless frameworks used for programming web services. Embedded programming requires you to write software for each device and then publish it to that device by deploying it. Web services (or server-client framework) don't require customers to bring their problems to the manufacturer; clients consume the resources from the server. Of the problems that occur, most happen on the server and not on the client side. Thus, once a problem is faced, the team only has to fix it in one place and not on every device.

There are a few benefits of using ASP.NET Web API instead of other web services frameworks.

Historically, ASP.NET has been used for building and deploying web applications in HTML, CSS, and JavaScript. However, ASP.NET started to roll out a new framework for programming called ASP.NET Web API. It follows the same architectural design as ASP.NET MVC and provides a very compact benchmark for HTTP communication, rather than having to submit and share HTML documents.

Based on experience, I believe that using ASP.NET Web API for the web services framework can ease many pains, such as having to create the clients and authorizing the clients that can communicate. This problem arose frequently while programming WCF web services.

Another common problem with WCF programming was that it required coders to generate certificates for the clients and then, using those service references, clients would be able to consume the services. However, what if you were required to consume a service from some micro-controller? Or if you wanted to consume the service from an Android device, where .NET framework is not available? In such cases, the WCF framework is not feasible, so you'd need a workaround.

Also note that WCF is a complex programming framework that requires multiple considerations and learning situations before you can start writing web services (and note that it is a web services framework for .NET applications only), whereas the ASP.NET Web API doesn't even require you to learn HTML, CSS, or JavaScript. You just need to understand the HTTP protocol in order to make things work.

This leads us back to ASP.NET. Just look at what MSDN has to say in this matter:

In the next guide Performance of ASP.NET Web API for IoT, we'll consider some more detailed comparisons of WCF and ASP.NET.