Re: [core] Observe Cancellation: The outcome

["Peter A. Bigot" <[e-mail]>]

On 03/08/2014 11:15 AM, Carsten Bormann wrote:
> On 08 Mar 2014, at 16:10, FOSSATI, Thomas (Thomas) <[e-mail]> wrote:
>
>> b) reusing an existing request code as GET (or any other already allocated
>>    method).
> (Personal view follows, no hat:)
>
> There is no “reuse”.
>
> This is still a GET: A client is obtaining a representation of the resource.
> At the level of the REST model, there is no change: These representations are cacheable, they can be operated on by chains of proxies (“layered system”) only some of which make use of Observe, maintaining a uniform interface, and so on.
>
> The details of how the GET request is operated are in the Observe request option (absent, =0, =1).
> Setting up an Observation relationship asks for future representations as well; renewing checks and possible re-establishes it, canceling ends the indication of interest.
> But this is not application state: This is entirely an optimization that saves polling (or, long-polling, which goes much further in the way of bending the REST principles).
> Saying this is “not RESTful” is tantamount to claiming HTTP is not RESTful because it involves setting up TCP state.

Agreed: There is no state at the HTTP (request/response transaction) 
layer; it's present at the TCP (data transport) layer, which is 
conceptually decoupled from HTTP in a RESTful system (e.g., HTTP/SMTP).

In CoAP, the state that's being created for -observe is being created 
and destroyed as a side-effect of a GET request (transaction), and is 
identified through a transaction-layer concept (Token).  So we can say 
there's no inter-transaction state preserved in an -observe operation 
because the transaction simply hasn't completed until something causes 
it to stop; all those requests/responses over long periods are the moral 
equivalent of IP packets, and the state required to support them the 
moral equivalent of TCP state.

This is an interesting perspective, and I see the argument.

> The Observation relationship state is not modeled as a resource, because it really isn’t one.

It's not a resource only because it was decided that it shouldn't be.  
It'd be a resource if you think of handling observation this way:

1) Create a resource representing a subscription from a client to a 
server, containing the URI of the resource to be observed and a URI to 
which changes to the observed resource should be sent.  (Creation does 
not have to be done on a server that hosts the observed resource.  
Exercise: why might this be desirable?)

2) Sit back and wait for updates.  (Notifications don't need to be sent 
by the owner of the observed resource.  Exercise: why might this be 
desirable?)

3) Delete the subscription resource when the subscription is no longer 
desired.

Sure there are details to be worked out, but this seems more RESTful 
(and clean and harmonious) than having subscriptions (aka state, at 
whatever layer) created and destroyed as a side effect of requesting 
transfer of a (representation of a) resource.

Something for CoAPbis to consider, or not.

Peter