JKI HTTP REST Client Library for LabVIEW

Simplifies Web Service and Cloud Connectivity

Jan 3, 2017 5:29:45 PM Published by Tomi Maila on https://blog.jki.net/labview
Because of its elegant simplicity, REST APIs have become the de facto standard for how
software communicates with other software over the network, including backend services
running in the cloud and computing nodes in a distributed system. REST is commonly used
by smartphone apps and web pages to communicate with web servers. It is even used
by smart cameras, home automation devices, and drones -- it's powering the Internet of
Things (IoT)!
At JKI, we help our customers design and build high-tech system, and we're seeing REST
rapidly move into industrial test, measurement, and automation systems -- it's a key
component in the Industrial Internet of Things (IIoT) revolution. We also share many
of our LabVIEW libraries and tools with the community, making them freely available as
open source.
Recently, we released our JKI JSON Library to improve LabVIEW interoperability with the
JSON document format. Now, we're proud to have just released our JKI HTTP REST Client
library to make it simple for LabVIEW developers to call RESTful web services. Together
these two libraries make LabVIEW a powerful platform for creating distributed test,
measurement, and control systems with cloud connectivity.
In this post, I'll be talking more about REST: what it is and why JKI created a REST client
for LabVIEW. In future posts, I'll show examples of how to use these tools, together, to
integrate your LabVIEW applications with RESTful web services.

What is REST?
REST stands for Representational State Transfer. It is an architectural style for designing
networked applications. Under the hood, REST relies on a stateless use of the HTTP
protocol. REST has replaced other (more complex and complicated) protocols such as
CORBA, RPC and SOAP, making REST the de-facto standard for how software
communicates with other software over the network.
RESTful web services implement the Create/Read/Update/Delete (CRUD) paradigm,
using the HTTP POST/GET/PUT/DELETE methods for each of the four CRUD operations,
respectively. For example, let's imagine we're calling a RESTful web service to perform user
management:

• to add a new user to the system the client would perform a HTTP POST request
with the user data as the payload,
• to update the user account information the client would perform a
HTTP PUT request,
• to get the user account information the client would perform HTTP GET request,
and
 • to delete the user account the client would perform HTTP DELETE request.

As a stateless architecture, each request to the web service is independent from all other
requests. The server does not maintain any session information about the client. Each
request is completely independent of one another and each response by the server includes
a numeric status code* indicating the success of the request.
*Note: status codes between 200-299 indicate a successful operation, status codes
between 400-499 indicate a client error and 500-599 a server error.

Why JKI HTTP REST Client?

To develop a client for a RESTful web service, the developer has to perform stateless
requests and interpret HTTP responses from the server in a RESTful fashion. This means
that the developer needs to have a full access to the underlying HTTP protocol including
ability to properly interpret the HTTP responses from the server. HTTP protocol encodes
information about the response in form of status code, HTTP headers and the actual
payload. To integrate with a RESTful web service the developer needs an easy access to
all of this information. Although it's possible to use LabVIEW's native HTTP client for
connecting with RESTful web services, this client has some limitations that make the use
cumbersome.
We built the JKI HTTP REST Client library to extends LabVIEW’s native HTTP client with
several powerful features, such as support for:

• HTTP status codes,

• response headers dictionary,
• request-specific HTTP headers,
• automatic escaping of URLs, and
• multiple parallel requests.

HTTP Status Codes

The biggest limitation of the LabVIEW native HTTP client is that it doesn't parse the status
code returned by the server. Status codes however are an integral part of RESTful web
service APIs. Status codes between 200-299 indicate a successful operation, status codes
between 400-499 indicate a client error and 500-599 a server error. It's critical for
developers to know the status code returned from the server when integrating with RESTful
web services. But, with LabVIEW's native HTTP client, there is no simple way for the
developers to know if the server responds with an error message or if the request was
successful.
The JKI HTTP REST Client improves on this, by parsing the status response from the
server and returning a numeric status code that indicates the success or failure of the
request. To make things even simpler for the developer, the JKI HTTP REST Client
generates a LabVIEW error (in the error cluster) if a request fails. Using the JKI HTTP
REST Client, developers don't need to worry about interpreting the returned status code
when they only care about the success or failure of the request.
Request Specific HTTP Headers
Clients communicating with RESTful web services are expected to use the HTTP request
headers to communicate metadata about the request to the server. As REST is a stateless
architecture the requests are independent of one another. Although some of these HTTP
headers are likely to be shared between the requests, it's not always the case. For example
the client may be expected to sign the payload with a secret and include the signature as an
HTTP header to the request. This signature would be different from request to request.
LabVIEW's built-in HTTP client would require opening a new client reference for each
request which introduces a significant performance penalty. JKI HTTP REST Client allows
developer to specify both common HTTP headers as well as request specific headers
making it easy to communicate with any type of REST services.
Response Headers Dictionary
RESTful web services make often use of the underlying HTTP standard for transferring
response related metadata. To access this metadata the client needs to easily check the
values of specific HTTP headers set by the server. LabVIEW's native HTTP client
implementation leaves it up to the developer to parse the HTTP headers returned by the
HTTP server which can be both laborious and error-prone. JKI HTTP REST Client returns a
response headers dictionary object that provides an easy access to the response headers
when the developer needs to access them. The parsing is done on-demand improving the
performance when response headers are not needed.
Automatic Escaping of URLs
When passing URLs, its important to use escape codes for special characters. For
example, ever notice how your browser replaces spaces with %20 (e.g. the URL
"http://server/my folder" becomes "http://server/my%20folder")? The LabVIEW native HTTP
client doesn't do this escaping automatically nor does LabVIEW ship with a VI that would do
the escaping properly. We built automatic but optional escaping of URLs into the JKI HTTP
REST Client, so developers won't have to worry about this.
Multiple Parallel Requests
In order to create a high performance application, it may make sense to send multiple API
requests in parallel. For example the client may request a list of all measurement in the
database and then request details of first ten measurements in parallel. JKI HTTP REST
Client keeps a connection pool allowing multiple parallel request to be made to the server
improving the performance of applications that need to query or send multiple items of
information at the same time.