Embedded devices that run HTTP client software have a convenient means of exchanging messages with “real-world” Web servers lying outside their local area network.
When Micrium first released the µC/TCP-IP stack over 10 years ago, one of the logical next steps was to develop a Web server. The thinking was that, for many embedded devices, a Web server provides a convenient user interface. Any laptop with a Web browser can be used to connect to an embedded Web server, to open pages indicating the server’s status, and even to send requests to the server via HTTP POST messages.
Potential uses for an HTTP client were not nearly as evident. It is often assumed that the client side of HTTP equates to a full-fledged Web browser, and such an application would obviously lie beyond the capabilities of an embedded system with limited memory and processing resources. Furthermore, many embedded systems, regardless of their processing horsepower, will not, at any time, have physical users sitting in front of them, a fact that would appear to make the inclusion of a Web Browser on these systems pointless.
An HTTP client implementation does not have to be Chrome, Firefox, or Internet Explorer, however. In fact, a client doesn’t even have to be a platform for viewing Web pages. HTTP, in its essence, facilitates data exchange – sending requests and receiving responses – along with a few related operations, such as identification, authentication, and resource routing. Accordingly, HTTP client really needn’t be any more than a device that sends requests to a server.
The reasons that might compel a developer of embedded systems to utilize such messaging capabilities begin to become apparent when some of the constraints imposed on a typical networked device are considered. Many devices, for example, don’t have the luxury of a carefully managed local network where they will run side by side with the computers used to monitor their status and control them. Instead, they must be capable of running on any local area network, and a means of monitoring them must be available inside and outside of that network.
These requirements can spell trouble for a developer hoping to use an HTTP server, running directly on a device, for status and control. A server is typically an always-on device, with a known address – or, at least, it should fit this description if it’s going to be of much use to any conventional clients. A device capable of being connected to any given local area network, however, must normally obtain an IP address dynamically, meaning that its address will vary depending on the network in which it resides. Even if its address happens to be known to clients outside the network, the device might not be able to function as an HTTP server unless its gateway router is configured to allow incoming requests from such clients.
Given the typical definitions of client and server, this type of device is much better suited to be the former than the latter. As an HTTP client, the device, instead of requesting Web pages, could send its status to an HTTP server managed either by the company producing the device or by a third party, and that server could act as the intermediary in monitoring the device. The server, with its known address, could be reached by a technician with a Web-capable phone or tablet from practically any location, and it could provide a status update from the device without any awareness of the details of the device’s local area network.
Of course, all of this could be done without HTTP – applications based on the client-server architecture can be built around any number of different protocols. The beauty of HTTP lies in the convenience that comes with its ubiquity. A developer relying on a custom application protocol would need to develop and test client and server code, whereas users of HTTP can often get by with existing implementations for one or both sides of the protocol. Additionally, the popularity of HTTP gives a device implementing the client side of the protocol easy access to a wide range of existing Web-based services, such as those provided by Dropbox, Gmail, Twitter, and other popular sites.
If you’re thinking of adding HTTP client capabilities to your next project and would like to realize the time savings of using an existing module, you can now turn to a high-quality implementation from Micrium: µC/HTTPc. This flexible client module was written according to Micrium’s rigorous coding standards, and it is ideal for use with µC/TCP-IP. More information on µC/HTTPc can be accessed via the module’s online documentation, and a µC/HTTPc example project, targeting the board and developed with the tool-chain is available from the Micrium download center.