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.
Download the JKI HTTP REST Client Today!
As you can see, REST is a powerful technology that is very important to LabVIEW developers. We've worked hard to make calling REST APIs from LabVIEW as easy as possible. We hope they give you a good head start in your applications and enable LabVIEW developers everywhere to join JKI in leading the Industrial Internet of Things (IIoT) revolution.
To learn more about JKI HTTP REST Client and other free JKI libraries and tools for LabVIEW, please visit our tools page. If you think we could help in designing software for your cloud connected equipment, send us a message to schedule a discussion with our engineers.
Have ideas or want to ask questions about the JKI REST Client? Join in on the conversation happening in the JKI HTTP REST Client community forum.
