Skip to content

Contact sales

By filling out this form and clicking submit, you acknowledge our privacy policy.

Performance of ASP.NET Web API for IoT

Sep 19, 2018 • 6 Minute Read


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.

Read my previous guide, Why Use ASP.NET Web API for IoT? for more information.


The performance of WCF and ASP.NET is good. Neither framework causes any problems in this case. Let's consider a simple API call.

      public string Get() {
  // Return the list of the data
  return dataList;

Performance depends on certain factors:

  1. CPU and RAM resources available for the programs to run; ASP.NET Web API can be hosted in a program.
  2. Network bandwidth and throughput.
  3. Other services running in the background.
  4. Time required by data engines to return the data or to load the data from the memory or files.

The rest is performed by the ASP.NET Web API to serialize the data to JSON format and send the data over the network. Most of the time, serialization and de-serialization of data can take a bit of time. Luckily, ASP.NET Web API uses the Newtonsoft.Json API to perform data (de)serailization actions and which are notably fast.

Even the entry level and outgoing level doors of ASP.NET Web API are fine tuned to not give any performance factor a hard time. This is what makes ASP.NET Web API a very powerful framework to create web services on the top of HTTP protocol.

WCF used an often inefficient amount of services to upload and run entire projects, no matter how small the memory benchmark, and handled it using TCP/IP. HTTP is based on TCP and doesn't cause the same problems in communication.

Self-hosting of Services

If you think that ASP.NET and WCF both require running entire projects in the same way, you're wrong!

ASP.NET Web API is an open source project and you can host the project in a minimal console application. This hosting method allows the project to consume the RAM and CPU resources for the required request handling and not for other services that are not at all required.

Yes, that is right, the only code required to host your Web API in the console program is the following,

      // Namespace references
using System.Web.Http;
using System.Web.Http.SelfHost;

 * This goes in the main function
 * The main function is required, rest is optional.

 // Create a new object with the address where you want to host the application at.
var configuration = new HttpSelfHostConfiguration("http://localhost:12345");

// Add the routing scheme, this is required.
config.Routes.MapHttpRoute("Default", "api/{controller}/{id}", new { id = RouteParameter.Optional });

// Start the service.
using (var apiServer = new HttpSelfHostServer(configuration))

  // Wait for the server manager to close it. Until then, anyone can connect.
  Console.WriteLine("Press Enter to quit.");

This is the code required to host the service, which you can host anywhere. The rest of the job is working with your ASP.NET Web API's code, which you use to actually handle requests. This code would forward the request to the API Controllers and they will perform the actions based on the HTTP verb being used. This enables your web services to run on very low memory and consume few CPU clock ticks.

The following are a few of the things that make ASP.NET Web API my personal favorite framework for building web services for connected devices.

Cross-platform Support

The popular WCF framework had another key problem: it was hard to consume services on platforms like Android, iOS, and micro-controllers. That problem was removed by using native protocols such as TCP/IP or HTTP.

Native protocols allow all devices to implement these protocols at their ease without issues. Unlike WCF, native protocols don't require any client-side certificate to be issued from the server. The ASP.NET Web API can be hosted in a small environment and it can also be published the servers where your enterprise libraries and cloud solutions can provide resilient, fast responses to the clients. This way, you can allow communication with any client over the HTTP protocol.

TCP/IP and HTTP protocols can be programmed on every platform nowadays, such as:

  1. Windows

    • Windows Runtime (Windows 8 and Windows 10 applications)
    • .NET framework
    • Native Windows services
  2. Linux

    • Android
    • Ubuntu
    • The rest of the Linux distributions
  3. Apple products

  4. Microcontrollers

As such, a native service would be consumed on every platform, so you won't have to worry about the underlying frameworks at all. Besides, using a native service also provides you with access to the native GUI and the native UX guidelines because you can access the data in the application itself and render it on the screen, speak it out, or print the data. Everything is possible, when you go cross-platform.

Next Steps

Continue on to my next guide, Building and Connecting ASP.NET Web API for IoT to delve deeper into building and connecting ASP.NET Web APIs.