PUT /guests/{userid}/disks sounds like it violates RFC 7231

[johnarwe]

PUT /guests/{userid}/disks says

Configure additional disks for a guest

and the request representation makes it look like it is modifying certain properties of one or more, but not necessarily all, of the guests already-existing disks (probably created earlier in time via POST on the same resource, but possibly also via other means like via the guest's creation request). Is this what's going on?

The problem with that behavior is that partial modifications (contrasted with complete replacements) of the request URI conflict with RFC 7231's requirements on HTTP PUT, specifically

The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation. The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics, whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. Hence, the intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server.

[jichenjc]

you are right PATCH might be more accurate one but this is what it is now
maybe we can create a PATCH for same function like PUT and overtime we can deprecate the PUT

[Bischoff]

I vote for changing it to PATCH too.

[jichenjc]

right, I fully agree , the reason is simple, with no expertise when we start feilong journey, we refer to openstack nova/cinder implementation and they don't have PATCH and other RFC recommended REST API .. so we only realize this later when almost everything done.. the plan might be support PATCH/PUT concurrently (as we have other code rely on this PUT) if PATCH is needed or better align with RFC..