Patch nested resources: mismatched types scenarios #1448
Description
Common use case of patching is using the same type as that of the original resource in the delta payload.
Even though same-type patch should be the encouraged approach, when working on issue #1263, questions have come up related to using different types in the delta payload. This issue is opened to discuss the desired behavior for patching resource using delta payload types different from type of the original resource.
Assemblies affected
*OData WebApi lib
Reproduce steps
We have the following type hierarchy:
Base type: A
Derived types: B (derived from A); C (derived from A).
and resources of CLR types A, B and C.
What is the expected result for these scenarios:
- Delta<A> patching original resource of type B: Should original resource data be updated with all changes contained in Delta, which is applicable for type B since A is the base type. This is the WebApi 6.x behavior but with whole-object-replace semantics, which is fixed by PATCH of nested complex properties not per OData spec #1263.
- Delta<B> patching original resource of type A: Should such request be rejected with HTTP-400 (bad request), since Delta<B> might contain derived-type data not applicable to original resource of type A. WebApi 6.x behavior is replacing the original resource with change tracking instance in Delta<B>.
- Delta<B> patching original resource of type C: HTTP-400, similar reason for case 2 since B and C are unrelated types?
Expected result
See Reproduce steps.
Actual result
See Reproduce steps.
Additional detail
Optional, details of the root cause if known. Delete this section if you have no additional details to add.