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

Thanks Michael and Claes, this gets me to the next point - where to document this information?  Presumably somewhere in the technical landscape document, but where exactly?  Section 4 "Tech landscape for APIs and protocol mappings” seems appropriate. However, none of the existing headings is a good fit. I’ve taken the liberty of adding a new subsection to section 4 based upon your response.

> On 2 Jun 2016, at 14:22, Michael Koster <michaeljohnkoster@gmail.com> wrote:
> 
>> REST or representational state transfer assumes that requests transfer the state of the resource, but what does that mean when it is constantly changing?
> 
> Good question. We have created extensions to the REST design style, both in CoAP Observe and HTTP EventSource, that allow for multiple serial state changes to be returned asynchronously in response to a request. The client/application simply responds to these using a handler and applies the resource state changes to the application state. 
> 
> For example, if the application is a thermostat, the asynchronous temperature state updates invoke a handler that evaluates the thermostat mode and other controls and decides, on each response from the sensor, whether to turn the heating system on or off, heat or cool mode.
> 
> Additionally, the pattern described by Claes below is supported in the notion of a subscription, or binding, where you may CREATE (POST) a control to a location that starts "web callbacks" which are POST or PUT operations sent to the destination address configured by the CREATE operation.
> 
> These patterns are becoming more well known and are described in the abstract transfer layer proposal.
> https://github.com/connectIOT/iotivity-servient/blob/master/docs/abstract-transfer.pdf <https://github.com/connectIOT/iotivity-servient/blob/master/docs/abstract-transfer.pdf>
> 
> In the CoRE Interfaces draft, there is a description of Observe Attributes, which are additional controls on the Observation. For example, the pmin attribute specifies the minimum interval between responses. By using pmin in conjunction with a content format that allows batch sample reporting (e.g. SenML) rapidly changing samples may be buffered at the source and sent as a batch in each periodic notification. Additional conditional observe attributes are defined and being defined to provide additional controls and filtering. These are appropriate for including in the payload when creating a subscription or binding.
> 
> Additionally, in a REST based hypermedia system, resources may be assigned media types and content formats that are designed for media streams. This works like a websocket upgrade, where a separate socket connection is made from the media stream data source to the handler in the application.
> 
> CoRE Interfaces
> https://datatracker.ietf.org/doc/draft-ietf-core-interfaces/ <https://datatracker.ietf.org/doc/draft-ietf-core-interfaces/>
> 
> SenML
> https://datatracker.ietf.org/doc/draft-jennings-core-senml/ <https://datatracker.ietf.org/doc/draft-jennings-core-senml/>
> 
> 
>> On Jun 2, 2016, at 4:54 AM, Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com <mailto:Claes1.Nilsson@sonymobile.com>> wrote:
>> 
>> 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 <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>>
> 

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