Conflict between Write(Update)/Create and Write(Update)/Execute

[sbernard31]

When a client receive a :

• CoAP POST on objectID/instanceID/resourceID, this may be a Write with update request or an Execute request.
• CoAP POST on objectID/instanceID, this may be a Write with update request or an Create request.

For the first one (write/execute), if the client know if the resource is executable or writable it could manage this. If the resource is WE, we're lost. (In all case, this complicate the code a lot ...) For the second one (write/create), there 're no way to know if the server want to create or update.

Maybe, we should always use PUT for Write and add a param in the query to define if we want an update or a replace The other solution is to remove the replace and define that a create on an instance which already exist do a replace (it this case a create request could receive a 2.04 response) and use PUT to do update but this mean we could not do replace at resource level.

But in all case, a Write with update seems to be idempotent, so this should be a PUT rather than a POST. http://tools.ietf.org/html/rfc7252#section-5.8.3

[ThGarnier]

These points will be addressed (and solved :-) ) in August. According to my view :
a) For the execute : if the spec fixes (Appendix D) the fact that the operations a resource can support are R(Read only), W(Write only), RW (REad and Write) or E (Execute) then a POST on a resource is not ambiguous any more : a POST on a Resource supporting 'E' operation is an EXECUTE, a POST on a Resource which doesn't support 'E' operation is a WRITE b) my proposal is to remove the OBJECT INSTANCE ID of the LWM2M CREATE command (the ID must be assigned by the Client, not by the SERVER which is more in the REST spirit) In that case no ambiguity any more : POST objectID is a CREATE POST Object_ID Object_Instance ID is a WRITE Make sense ?

[sbernard31]

a) This is a possibility, but I really don't like that 1 thing at CoAP level means 2 potential things at LwM2m level. A model desynchronization between server and client could involve strange behavior. A server could sent a Write request and the client should take this for an execute instead of returning an METHOD_NOT_ALLOWED

b) Make a create without ID avoid to try to create an object with an ID which already exists. Make a request with ID avoid we create several objects if the request is sent several time. I don't know what is the best one. But I still think that the Write request should be a PUT as it is idempotent.

So I prefer : POST for create and execute. (POST is neither safe nor idempotent.) PUT for write with an option for replace ( PUT is not safe but is idempotent.) source : https://tools.ietf.org/html/rfc7252#section-5.8.3

[sbernard31]

Finally, I think the right solution should be to use the PATCH or IPATCH method defined in : https://tools.ietf.org/html/draft-vanderstok-core-patch-02

POST for create and execute. (POST is neither safe nor idempotent.) PUT for write/replace ( PUT is not safe but is idempotent.) IPATCH for write/partial update (iPATCH is not safe but idempotent)

This seems to be the more elegant way to solve this issue.

(As I understand the spec the partial update is idempotent but if I'm wrong we should use PATCH instead)

[ThGarnier]

Has been addressed and fixed in OMA-TS-LightweightM2M-V1_0-20150910-D
=> to be closed

[sbernard31]

For the conflict create/write on objectInstance, sounds good.

But for excute/write, as I explained previously I think that having 1 thing at CoAP level meaning 2 potential things at LwM2m level is a mistake ...

So for me, this should not be closed.

[ThGarnier]

Yes, after verification, you are right : thanks for this !! in the meander of this fix & discussions (CR) few points unlikely disappeared. For instance the fact that operations 'R,W' from one side and 'E' on other side MUST be exclusive (only E, R,W, RW are acceptable operations in Object Template) . So, yes this issue must be kept open :-) on that aspect.

[jvermillard]

From an implementer point of view this is not practical, we don't want to look at the object model for knowing if we need to call the EXEC routine or the WRITE routine.

[sbernard31]

Maybe this one #83 should be taking in account too.

[jvermillard]

addressed by OMA-DM-LightweightM2M-2016-0007-CR_Partial_Update

[ThGarnier]

So all aspects are now covered in (even before) the TS1.0 20160407 :-) => to be closed

[Megan-OMA]

Issue closed per Thierry's latest comment.