rest - RESTful interface for ECG/EEG sensor data in haskell -

i'm working on project in want display biosensor eeg/ecg data measured portable device (e.g., micro controller wireless data transmission via wifi or bluetooth). purpose, need interface portable device/microcontroller, many or of device seem use restful interfaces, offer sockets.

one example of microcontroller wifi "spark.io", based on cortex m3 , cc3000 wireless controller wifi access on-board. data transferred around 500 1000 float values per second, should arrive @ rest client little delay possible. non-rest approach sockets fit better, still test approach based on restful interface (a tiny argument transferring data via resful interface seems common , has library support).

q: question is, best approach performant (in sense of near-realtime) implementation interfaces via rest interface?

i sure problem has been solved before, not find paper via google scholar or technical/scientific blog post explains this. link found on "rest hooks", not sure if approach. searching on se didn't reveal past question on this.

side note: approach implement interface in haskell first test design , performance of resfull interface. later working approach should ported or implemented java/android/spark.io/some other microcontroller.

(please note question entirely architecture , not @ haskell libraries or anything. if using rest stupiest thing, accept answer if argumented. question whether in general microcontroller web-interfaces , specically apis, of "spark.io", in general stupid idea, if implemented via rest. case? if not, definition of "near real time" justifies rest interface bad idea , other means of communcation better. like: 1 sensor read per minute? or, 1 per second, 1/10 second, 1/100 second, 1/1000 second?)

okay, let's go through this.

rest not bad idea has lot of features may not need. example, there rest verbs not retrieval, updating, deleting, , creating resources. if functions important (e.g. need send control data eeg controller) rest nice. if want fast access stream of data, consider raw tcp instead.

similarly, rest package messages "requests" , "responses" come bunch of "headers" indicating things whether request fulfilled, whether it's compressed, etc. these can great features may bloat. you'll want emit enough data on each request ~1kb of headers small fraction of it. given 8-byte floats (doubles), requires transmitting 500-1000 data points, you've said take 1 second. our fate -- have 1s of latency?

rest allow avoid of bloat declaring transfer-encoding: chunked client can operate on individual chunks become available. that's architectural decision think need made.

i keep-alive working possible, , chief feature when looking library use on server. keep-alive standard extension http avoids tearing down , rebuilding tcp stack each http request. if don't have heavy protocol negotiations each time send request.

a crucial decision you'll have make involves whether want http pipelining or not. can combine http pipelining longer-lived requests (ones don't expect immediate response) "send data when becomes available" (i.e. send headers first , let server push out data when it's , ready). alternative chunked transfers.

if can work out, http regularly used send megabytes per second, use case fits within rest capable of. in terms of rest/http libraries haskell, if have somehow program controller yourself, big options wai, yesod, snap, , rest. if need http client there few of too.