Allow DELETE to return a 200 status and payload

[lmd59]

Summary

Updates fhir-response-util to allow a 200 response with a payload when the passed json object has a Bundle or OperationOutcome resource type.

New behavior

Returns a 200 response and payload if a Bundle or OperationOutcome object is passed through.

Code changes

• Update fhir-response-util/index.js to return 200 and payload under the correct circumstances (and otherwise continue to return 204 status code).

Testing guidance

npm link or use local folder to link this update for use in measure repository dependencies and test that a DEL on one of the artifacts returns a 200 and bundle. The bundle should have the deleted artifact and any children artifacts (all of which should have been appropriately removed from the server).

Notes:

The http specification https://www.rfc-editor.org/rfc/rfc7231#section-4.3.5 indicates that a 200 response message on a DELETE "includes a representation describing the status." We can see an example of what this means in the MDN web docs: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/DELETE

Responding with a json representation of the deleted docs may not clearly imply the successful deletion (status) of those documents, so we may want to change this approach or further discuss the response bundle. We could also consider using a header to specify information about what objects have been deleted.

Previously, our remove function returned an object of structure { id: string, deleted: bool }. Ideally, the server would continue to respond with 204 for this case. When/if the DELETE response bundle is defined, we need to be able to consistently differentiate it from the remove function object structure (initial approach here is to look for Bundle or OperationOutcome type).

We could potentially return an OperationOutcome or a Bundle of OperationOutcome(s) as long as we could appropriately identify the deleted objects within the OperationOutcome(s)... in the expression(?), or in the details of the outcome i.e. MSG_DELETED_ID The resource "%s" has been deleted

Update:
The ideal response for us may be a transaction-response bundle as described here and implemented in measure-repository here. The transaction-response bundle type implies:

The bundle is a transaction response. Because the response is a transaction response, the transaction has succeeded, and all responses are error free.

As such, this can act as a success status. But the changes for node-fhir-server-core are still a bit more open ended so potentially other servers could respond differently if something like an OperationOutcome is more appropriate for conveying status for that server.