extension to Yun REST Api

[Jeff Hoefs]

First of all, nice job on the Yun! Finally managed to get one and loving it so far. One thought I had for an improvement would be an extension of the REST Api to provide (suggested) interfaces for various sensors and actuators. These would be sensors and actuators that you couldn't easily use via the existing pin routes.

For example, what would an accelerometer or gyro API be or a stepper motor api. What this would do is enable users to create applications that may use different hardware, but the applications would be interoperable due to the standardized interface the rest API could provide. For example:

http://myArduinoYun.local/arduino/accelerometer/x/y/z

http://myArduinoYun.local/arduino/stepper/numSteps/direction/optAccel

Of course currently anyone could create any combination they want, but by providing a suggested api for a number of common sensors and actuators it would be more likely that an interoperable platform could emerge.

It would take some thought and discussion to get alignment on what such an API would be. I'm happy to start a shared doc if anyone want's to participate. Or is there already an effort here?

To take it even further (and this is likely a separate discussion) it would be nice if the API could work over either REST or WebSockets (although in WebSocket form it may be better to use JSON, but maintain the same 'params' the REST api would have for sensors and actuators). The WebSocket approach would be much faster for applications where the user needs to send and receive a lot of data since you just need to establish the initial handshake over http and then once the socket is open you simply pass data back and forth. The existing SpaceBrew example does this via an external WebSocket server (Yun only has a WebSocket client as far as I can tell). Having an onboard WebSocket server would enable web applications to communicate with the Yun without the need for an external server (even though the SpaceBrew is a better model for more production-oriented applications where you'd need an external server anyway).

-jeff

[Jeff Hoefs]

Realized my accel example was total garbage. Would be something more like this:

http://myArduinoYun.local/sensor/accelerometer/deviceNum/vector

To request a reading. This would return something like:

{ accel: {

  id: 1,        // would need a way to identify which device in case there are many

  x: 0.98,

  y: 0.76,

  z: 0.02,

  range: 2   // dynamic range of the sensor +/- 2 G for example

  }

}

Seems /arduino/ is for pins so would need something like /sensor/ for sensors and /actuator/ for actuators perhaps.

Another way to think about this is to look at how Android works with hardware. There are tons of Android devices and they don't all have the same sensors. However sensors must conform to a common interface in the Android SW layer. In the case of the Yun and the REST API, the API could serve as this common layer to which people could develop web application regardless of the exact hardware wired to the Yun.

-jeff

[Tom Igoe]

Mailed Julio Terra about the SpaceBrew implementation on the Yun; he said it can indeed do the server side too, but it requires a patch to the space brew.py field. He said he'll submit that patch sometime in the next few days, and he's happy to help anyone who needs it sooner, so mail him if you do.

re: REST API, I think that's a good thing and users can and should be able to make up their own. The Bridge example is meant to provide an example of that, but others would be good too. I'd say submit a few examples as patches and we can talk about them. The less code, the better, though, is always my mantra. For example, the accelerometer example could be as simple as three analog reads, and a modification of the Bridge example to provide /accelerometer/x/y/x instead of /analog/0, /analog/1, /analog/2

Thinking it through like that, it's probably a best practices tutorial with a few code snippets as examples.
t.

> --
> You received this message because you are subscribed to the Google Groups "Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

[Jeff Hoefs]

Thanks for the info Tom. I'll follow up with Julio about the SpaceBrew stuff.

For the accelerometer example, It would be nice to cover digital accelerometers as well. That way there is a single interface that can be used regardless if you use an analog accel, i2c or spi accel. The person writing the arduino sketch in such a case would have to implement the correct interface for this to work but that's the point of 'standardized' interfaces. However there could also be light library to help with that (and also reduce the amount of strings required in the JSON response since the python code on the Yun could resolve the serial data and produce a more meaningful response to be consumed by the web application).

-jeff

[Tom Igoe]

You could. The REST interface should be technology-agnostic, which means when you choose your accelerometer, it's your job to stick the results into the REST API.


t.

[Tom Igoe]

FWIW, here's a lightweight example that implements a custom REST interface for controlling an RGB LED. This is more or less along the lines I was talking about:

https://github.com/tigoe/NetworkExamples/blob/master/BridgeRestRGB/BridgeRestRGB.ino

Working on a basic accelerometer example for it to show what I mean.

t.

[Jeff Hoefs]

That is exactly what I was thinking. Happy to contribute some more examples.

-jeff

[Tom Igoe]

Added two examples, BridgeRestAccelerometer and BridgeRestParser to get you thinking, in that same repo. Off to meetings for the REST of the day now.

t.