Finishing up the API Economy Business Drivers and Use Case Categories series our final use case category is IoT – Internet of Things. I will focus on the methodology I use to identify API use cases so you can apply this to your specific business. As a reminder, you can find industry examples for APIs across the use case categories linked here.
Devices typically have a specific purpose, so there is no surprise that the APIs involved with the device would be to take advantage of that purpose. As an example, a camera takes pictures or videos. The APIs for a camera would involve pointing the camera in a direction, focusing, zooming in or out, taking a picture or start/stop the video, sending the picture, etc. Some more complex devices (such as automobiles) may have a substantial number of components that can be API enabled and there may be many scenarios.
- A device sends data via API call.
- A device is sent a command via API call.
- A device sends data through a non-API call using other technology such as MQTT—a high-volume messaging protocol and transport for telemetry devices—because not all data calls require an action. However, APIs access the data inside the organization and look for or react to situations or events.
Defining the APIs for a device is less interesting than defining the use case scenarios around the use of the device APIs. So, I intend to focus more on the use cases and less on definition of the actual device APIs, especially since in many cases the device APIs may not be in your control (unless you are the device manufacturer).
Before diving into the API use case identification, I want to point out the potential need for security and an indirect invocation of device APIs. I covered this in “Internet of Things APIs – Focus on Security”. For sensitive, secure, private, or other reasons, a person requesting an action on a device must be authenticated and their authorization for the action validated. As described in the blog, this could involve an indirect invocation through a request to an enterprise to check the security and then an invocation by the enterprise of the device API. Making device APIs directly accessible by a consumer without API management implies that security and management are not necessary.
Let’s look at a variety of scenarios across the three models identified:
Data sent from a device
- Automobile needs to be maintained or repaired. Information is sent to the automobile owner and automobile dealer
- Automobile safe driver validation information is sent to the insurer for premium discount
- Beacon / sensor in retail store identifies customer location and opportunity to market nearby product.
- Manufacturing automation identifies completion of one part of the process. Administrator or another device may be notified to take appropriate next action.
- Safety / security sensor identifies a person in a location where they should not be
- Healthcare monitor in hospital raises alert that patient needs attention. This may invoke an alarm and/or send notification to the medical staff.
These are examples where the device sends data to a consumer who will use the data to start a business process/activity or take other action based on the data. Additional APIs might be invoked to display information on a mobile device or invoked to continue an automated process.
Command / Data sent to a device
- Automobile owner wants to unlock door, start the vehicle, adjust the climate controls
- Security camera control operator wants to control the camera direction (panning) and zoom in or out.
- Healthcare device (e.g. level of medication) needs to be adjusted based on readings. A doctor is sent the information and is authorized to adjust the medication level delivered.
These are examples where the owner, manager, or administrator of the device wants to cause an action by the device. As previously mentioned, appropriate security should be in place. The request for the action might be done from a mobile device invoking an API to request the action to occur. A second secured API call to the device itself might then be invoked to cause the action to occur.
Acting on events
- Automobiles may send GPS coordinates as they travel. Manufacturer collects data and sells access to the data via API (in aggregate) to partners/other industries who use the information for marketing
- Health monitor is worn by patient sending monitored data to healthcare provider (or clinical trial). An application viewing the data acts upon abnormal data or patterns to take action (e.g. send assistance) via API.
These scenarios are a variation of the data being sent scenario. In this case, massive amounts of data may be sent, most of which requires no action. The data itself may then be accessed via API or a program viewing the data may invoke an API to take an action.
IoT API scenarios are usually part of a larger process which may invoke other non-device APIs. The use of IoT APIs often enables new and innovative business models.
I hope you have found this series useful. You can find pointers to all 4 of the business drivers (speed, reach, innovation, and domains) and the 7 use case categories (mobile, social, data, other, partner, public and IoT) from the series overview. Let me know your thoughts. Are there other business drivers that you see? What other API use case categories are you implementing?
To understand more about IBM’s thoughts on the API Economy visit the IBM API Economy website. IBM API Connect is IBM’s complete foundation to Create, Run, Manage, and Secure APIs. You can find more information about IBM API Connect at the API Connect website. And you can also experience a trial version of API Connect.
If you have questions, please let me know. Connect with me through comments here or via twitter @Arglick to continue the discussion.