Reaching much more developers – REST API

[regular]

I really like that you are working on an open API for your devices! This effort makes your products much more attractive to developers. By having a nice to use API, potentially a software ecosystem around your products may form that drives artists, makers and an even wider audience towards it. This really can set you apart from other brands.

That having said, I think you limit yourselves by offering language-specific or platform-specific SDKs. The reason why you currently support Java exclusively probably is the fact that it's a lot of work to build these SDKs. You'll have to allocate a lot of developer resources within your teams to build and maintain a whole set of SDKs for different languages and no matter how many languages or platforms you support, some devs will always be excluded. I saw many poorly maintained, outdated and buggy SDKs for exactly this reason.

There is a better way that requires way less work on your end, and supports all languages and platforms, including the most exotic ones running on tiny $2 embedded devices. Move your API to the http layer. Your cameras have Wifi and maybe even support Ethernet-over-USB? Then you can easily implement an http server with various REST API endpoints and use JSON to serialize data structures.

http and JSON are supported by all programming languages, because they are required to talk to all of the web services out there. There are well-tested and robust implementations on all platforms and even junior developers and web developers know how to use them.

By focusing all your resources on designing, building and documenting a REST API, you could create a very polished, accessible and fun to use programmatic interface to your devices that would be attractive to the developer community as a whole.

By carefully mapping your devices' components to URLs, you can make that API really intuitive. Imagine:

curl http://myyi4k.local/sensor/settings
{
  "iso": 100,
  "resolution": {
    "x": 4000,
    "y": 3000
  },
  "framesPerSecond": 30
}

curl http://myyi4k.local/battery

{
  "charge": 0.75,
  "secondsRemaining": 6000
}

curl http://myyi4k.local/firmware
{
  "version": {
    "major": 1,
    "minor": 0,
    "patchLevel": 13
  },
  "releaseDate": "2016-10-14"
}

curl http://myyi4k.local/storage/IMG-23124.jpeg
[jpeg data]

Some of these settings would be writable via POST or PUT requests, firmware updates could be done by POSTing to /firmware/image, the camera's shutter could be triggered by POSTing to /shutter, the current live video frame could be requested from /sensor/frame. Pre-existing http infrastructure projects (proxies, caches, etc) could be easily combined with your device without any custom software to build more complex system and everything would seamlessly integrate with Internet-of-things devices and, most importantly, the web. Imagine all those people out there knowing jquery could easily remote control your devices. But, on the other end of the spectrum, the Erlang or C++ and Java developer is also happy. because they can use their favourite HTTP client library and don't have to learn a bunch of new stuff.

Http is a good mach for live streaming, remote control and content management.

One of the first things I would do with that API would be controlling an action camera with this tiny chip. The possibilities are endless! No chance that a Java VM will ever run on it. Or maybe, the first thing I'd do would actually be writing a module for NodeJS that could be used in a Node-powered Quadcopter (Nodecopter).

I hope these thoughts are useful to you.

Jan

[deepzf]

@regular I agree with you

[rob-ert]

If there is a mechanism in place to validate the correctness of the JSON payload before and after sending I still doubted that above proposal actually reduces (code) complexity and makes me wonder what this API/SDK would gain by changing the trasport layer for those tiny messages between camera and appliance.

Sending the payload around isn't the problem. Parsing and using it is rather ugly. See for example the Camera class. You have to extend something just so you can override almost completely everything in your implementation. Anonymous classes, inner classes, magic numbers like selectCameras(10 or 7 or maybe 6) and a 'listeners waiting for events' based approach deservers in my opinion more attention (heavy refactoring so to speak) than changing the transport layer to get a view characters from A to B.

Thanks for listening.

[strangerism]

it's 2018 now, so did they add support for REST API? It's the only way I would be able to use the YI 360 VR cameras for my project, because I need to remotely (e.g. from a backend server app) issue commands take pictures and download the picture file to server. Please let me know if this is possible, many thanks