MsSql/PgSql : UpsertById REST PUT

[Aniruddh25]

Abstract Operation​	SQL DB / PG​	Doc API​	REST​	Notes
UpsertById​	“UPSERT” <1 row w/ overwrite>​	upsertItem(item)​	PUT Orders/[PK]​	​

[seantleonard]

Prior to picking this up, please check status of #23 as mutation base elements to be added by PG team (Jelte/Gledis) first then we can iterate. Avoid duplication of work as base elements similar across REST/GraphQL

[seantleonard]

Find item by id -> update structure. otherwise insert

[seantleonard]

Proposed design:

Microsoft REST Guidelines

Implementation adheres to Microsoft REST Guidelines

Creating resources via PATCH (UPSERT semantics) Link

"Because PUT is defined as a complete replacement of the content, it is dangerous for clients to use PUT to modify data. Clients that do not understand (and hence ignore) properties on a resource are not likely to provide them on a PUT when trying to update a resource, hence such properties could be inadvertently removed. Services MAY optionally support PUT to update existing resources, but if they do they MUST use replacement semantics (that is, after the PUT, the resource's properties MUST match what was provided in the request, including deleting any server properties that were not provided)."

Sample Requests

1. PUT https://localhost:5001/books/id/1

• If object exists:

JSON Response: HTTP 202 Accepted
JSON Body: Operation-Location:<resourceURI>

• If object does not exist:

JSON Response: HTTP 201 Created
JSON Body: Operation-Location:<resourceURI>

Implementation Notes

Built to handle both inserts and updating an item with only the parameters included in the request,
while deleting/nulling out fields not included in the request.

Tests

UpsertById

• PUT operation on existing item updates the item with declared parameters, nulling out non-included parameters (that are nullable per schema).
• PUT operation on non-existent item, inserts that item with declared parameters.
  • (Neg) if autogenerated parameter defined in request body -> 400 Bad Request

[Aniruddh25]

This represents Case 2 of the PUT behavior outlined in the project-hawaii issue: https://github.com/Azure/project-hawaii/issues/50