API Design

Over the past few months, I have been finishing various assignments to complete the bigger picture: the software for the University of Hawaii Solar Decathlon house. For this assignment, Team Gecko completed the application programming interface, better known as API, for this managing this house. In general, an API must be general enough to handle various situations, yet specific enough to fulfill a predetermined objective. For instance the standard Java API exists to standardize an object oriented programming model across differing CPUs, but keep its functionality to system orient functions. As such there exists other API to target specific functionality such as graphical interfaces with Swing API or HTTP servers with Servlets API.

This API specification is not for the communication of the user interface with the house. Rather, this API is for interfacing the house system devices with the iHale system. For this API, there are a couple of assumptions that need to be made. The first assumption is that the house will have a local IP-based network; thus, each house system will have its own IP address. With its own IP address, the house systems can implement the REST architecture for communication. For example, the lighting system’s light color can be changed by the PUT command. In the case of GET, the house system will return XML data. The GET and PUT access methods have been defined in Team Gecko API.

Since REST api defined the house system’s information, the Java api must implement a method to interact with that information. For the Java api, each system was given an system and a database class. The system class is defined by the GeneralSystem class where four main attributes are the same across each system: title, description, status, and time stamp. While title and description will be static information regarding the system, the status and time stamp will be dynamic to the polling of the data. The status attribute describes the state of the system such as alive, down, or maintenance mode. For the time stamp, this is generated at each poll of the house system. In this way, the house system sensor device does not necessarily need to poll the devices every second, but rather can poll its sensors at preset intervals.

In addition to the basic house systems, the house will have a sensor for energy consumption which will be handled by the eGauge system. This system already has a defined xml output for its device, so the Java api needs to only define the interface for the eGauge xml.

In the end, I was not able to add details regarding the REST api specification, but I was able to finish the Java api according to the REST api.