RE: How relevant is REST to rapidly changing sensor readings?

Hi Dave,

For HTTP the alternative to chunked encoding for streaming blocks of sensor data as HTTP responses could be a two-step approach:


1.      Application to sensor: POST with payload of a URL to POST subsequent sensor readings to

2.      Sensor to application: A series of POSTs with sensor readings.

BR
  Claes

From: Dave Raggett [mailto:dsr@w3.org]
Sent: den 26 maj 2016 13:36
To: Public Web of Things IG
Subject: How relevant is REST to rapidly changing sensor readings?

I have been hacking away on an implementation of CoAP for the Arduino environment and am wondering just how relevant the idempotency properties of get, put and delete are to use cases involving rapidly changing sensor readings, especially, where each packet needs to transfer a block of sensor readings.

REST or representational state transfer assumes that requests transfer the state of the resource, but what does that mean when it is constantly changing? Consider a 3 axis accelerometer. The server path identifies the accelerometer, and get requests result in the most recent N samples. Each get request thus returns different data.  Perhaps we should use get? Should we instead use post for pulling or pushing such data?  CoAP’s observe capability allows a server to return a sequence of responses, and could be used to stream a sequence of blocks of sensor data. Likewise, you could use the HTTP chunked encoding for streaming blocks of sensor data as HTTP responses.

Perhaps REST isn’t a good fit, and we should avoid bending it to fit use cases for rapidly changing sensor readings?

—
   Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>>