As previously demonstrated by Google Glass developer advocate Timothy Jordan at the South by Southwest (SXSW) festival in Austin, Texas, applications for Glass are web-based services, now dubbed “Glassware”.

The documentation for the API also breaks down the flow interactions between the Mirror API, the Glass hardware, the developer’s service, and the user. Such examples include a fictitious Cat Facts service, showing how information from a service eventually reaches the user and can be expanded upon to allow the user to transmit photos back to an “Add a Cat to That” service.

It also has a playground where users can experiment with requests sent to the Mirror API to see what they would look like when they appear on a user’s Glass.

While posting data to users’ Glass appears to be relatively well documented, access to other aspects of Glass’ hardware has not yet been documented. At the moment, there doesn’t appear to be any support for retrieving a camera feed or an audio stream, but the user interface guidelines do provide some hints as to its hardware capabilities.

Google recommends sending images and video in a 16×9 format, and keeping sent information within a 640×360 resolution. It also supports H.264 and H.263 video, and AAC and MP3 audio.

Developers seeking out sample code to get started with creating glassware can either copy code from the site or subscribe to Google Glass’ GitHub repository. In terms of support, Google has an issue tracker, but its own developers will also be on Stack Overflow, using the google-mirror-api tag.

Those using the API are expected to adhere to a set of developer policies set out by Google. These include straight-forward general rules and what Glassware shouldn’t do, but given the potential use of personal information, it also includes a requirement that in the event of a security breach, developers must notify Google. If private user information is breached, developers are also required to notify their users.