The OTA blog series left users with a secured OTA Connect server. This article will describe how you can deploy an easy-to-use REST API to manage your devices.
You’ll need an OTA Connect service deployed into GKE as documented in part four of the blog series.
While OTA Connect is built around a set of backend REST APIs, they don’t include a unified front-end API designed for public facing usage. We created the OTA API with the goal of making a project that handled all the generic aspects of OTA device management while leaving room for people to implement their own management policies.
The OTA API is easy to try out locally. Follow along with the README to test things out before deploying to production.
Go to your OTA Community Edition deployment repository that should be on the
ota-blog-part4 branch and checkout the
# https://github.com/foundriesio/ota-community-edition/tree/ota-api-1 cd <repo> git fetch git checkout ota-api-1
The interesting changes to enable the API are in a
It creates a new “api.example.com/devices/” endpoint that requires the
BadT0ken5 used in the “oauthful” container. It can be deployed by running:
./contrib/gke/make SERVER_NAME=ota-ce.example.com DNS_NAME=example.com start-services
You can then validate the API is running with:
curl -H "OTA-TOKEN: BadT0ken5" http://api.example.com/devices/
You’ll probably want to customize things to match your organization’s requirements. For example, limit how many devices a user can create or which devices a user can see. The ota-api-1 branch includes a commit to give you some ideas about what to change. As your complexity increases, you’ll likely want to build your own OTA API container. There are different approaches that work. Here at Foundries.io, we extend the “foundries/ota-api” container and add our private implementation sources to produce a customized container.
Lastly, I’ll be creating a follow-up blog to this to demonstrate how to streamline device registration by extending this API.