Hi Gregg, I’m thinking you’re mixing “safe” and “idempotent”. There is some contention about how the term “idempotent” applies to RESTful interfaces, but the CoAP RFC at least clearly defines what is meant (“safe” means essentially no side-effects; “idempotent” means that there isn’t an order-dependency to operations on the RESTful interface… for more thorough description see the CoAP RFC). In CoAP, the GET, DELETE and PUT methods are idempotent; the POST method is not. If you think about that, it’s sensible: you don’t want DELETE(r1), DELETE(r2) to have a different outcome than DELETE(r2), DELETE(r1) because UDP.
But back to the GET method (because the others are a tangent): the GET method must be “safe” (that is, no side-effects) and therefore altering the Resource on GET. That is *not* the same, of course, as saying two GETs must return the same value. Thus your Hue example isn’t really right… the GET method will reflect the current state of the Device, which may change, but NOT as a result of the GET itself. Your GetNextIterator() example is therefore illegal in CoAP’s definition of RESTful GET… you would need a different interface definition to separate the GET from the POST (increment). In any case, as I said to begin with: Ethan’s use case is okay, as long as the results of GET to /oic/res aren’t changed by his side-effect functions that are triggered by GET to /oic/res. E.g. kicking off an unrelated operation would be fine; modifying /oic/res would not. Thanks, Nathan From: Gregg Reynolds [mailto:[email protected]] Sent: Friday, April 27, 2018 1:12 PM To: Heldt-Sheller, Nathan <[email protected]> Cc: Wright, Ethan J <[email protected]>; iotivity-dev <[email protected]> Subject: Re: [dev] oic/res entity handler On Tue, Apr 24, 2018, 7:40 PM Heldt-Sheller, Nathan <[email protected]<mailto:[email protected]>> wrote: Ethan if I’m understanding right, you basically want to “do something” in the Server’s application layer, when the Server receives as discovery request (multicast to /oic/res). If that’s right, I think you’ll need to modify the stack… I don’t know of any way to “hook” the in-stack “entity handler” (the request endpoint) for /oic/res. Your alternate Resource approach is more in keeping with the Specification (since side-effects on Discovery aren’t really a thing, AFAIK), but if that doesn’t work for your use case, then I think you’re looking at editing IoTivity code. Shouldn’t be too hard really but just make sure you are careful to not create side effects that change the Device/Resource state from an OCF perspective… that would be out of line with RESTful nature of the OCF Reource interfaces… make sense? Makes perfect sense in the context of the REST model. Unfortunately the REST model makes no sense in the context of interactionist computation. E.g. idempotence is completely meaningless outside of mathematics and/or Turing (functional) computation. The REST model is procrustean. Just think about what GET means. It should return the state of the resource. This will obviously not be idempotent for sensors. Or gowsabout GET /number/of/gets. But there is also no reason it should be idempotent for /oic/res (or any other resource). If the target has added or removed Hue resources since the last GET, then its /oic/res state has changed. I see no reason why the DISCOVERY handler should not mutate the state (side-effect) to reflect current state of the entire system. Put differently: how can a DISCOVERY handler possibly guarantee idempotence? It would have to remember the state as of the previous request. Easy peasy for Turing computation, since that is encoded in the structure of the computation. Impossible for interactionist computing. OCF servers are black boxes, we should not even talk about their state. Same goes for all the other CRUDN methods. E.g. if I get flooded by requests to turn the lights on, then I turn the lights off. Nothing wrong with that, it just doesn't fit the (procrustean) model of RESTful computing. Side-effects are not even possible in Turing/functional computing. They are normal and expected in interactionist computing. What does "side-effect" even mean, from the client perspective? IOW what Ethan wants to do is perfectly ok, no matter how many side-effects are involved. The REST notion that GET should never change the resource is completely incoherent, AFAIK. (I hope that didn't sound overly rantish. Kinda thinking out loud.) Gregg
_______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
