Implement REST over BLE

[jackjansen]

A wild plan for implementing REST over Bluetooth LE.

Implement a service with three characteristics: DATA, COMMAND and REPLY. Data and Command are write-only, reply is notification only (or the other one, I keep mixing them up).

To send a REST request you first do a number of writes to DATA (all of the request JSON data) and finally you do a write to COMMAND (a string like GET /api/foo). The server has buffered the data, executes the RESR request and sends the result back in a number of notifications to REPLY.

@troeggla do you have any idea whether this is feasible? Assigning to you for feedback/ideas, please assign back.

[jackjansen]

In private conversation Tom said he saw now problems and it seems workable. So let's give it a try.

[jackjansen]

Just found HPS, the Bluetooth HTTP Proxy Service. https://www.bluetooth.com/specifications/specs/http-proxy-service-1-0/ It is primarily intended to allow creating a gateway server (with BLE and Wifi connectivity) that will forward HTTP requests from BLE-only clients to the web.

Unfortunately it limits body size to 512 bytes or thereabouts.

It's somewhat similar to what I sketched above, with a few differences:

• Same buffer is used for request and reply body.
• There's a separate characteristic for URL and "execute".
• There's a separate characteristic for status code (notify) because with the remote HTTP request case you don't want to withhold the execute-reply status.
• There's a buffer for headers and such.

[jackjansen]

Implemented my original idea, with original protocol (so allowing large requests)

But I'm wondering whether it isn't a better to stick with HPS, despite the 512 byte limit. That would be a standard BLE protocol, and if you need to talk larger requests/replies with the device you can always use blerest to have it reboot with wifi, and then use normal TCP/IP based http(s).

@troeggla any comments?

[jackjansen]

Implemented HPS and merged.