Cannot create an AuditEvent resource via a PUT request

[tswelsh]

Describe the bug
To preface: this might be intended behaviour but I wanted to check.
I am working on an application where we write AuditEvents to more than one place. We would like to choose the Id of the AuditEvent in the FhirServer in order to keep it consistent across the different places (i.e. use a client defined id). Although the server is configured with updateCreate = true, it rejects the PUT request for a new AuditEvent. I think this is due to the AuditEvent special case in the CapabilityStatementBuilder, combined with the upsert code path always checking for update permissions on the resource.

To Reproduce
Steps to reproduce the behavior:

1. Send a PUT request with the appropriate body to /AuditEvent/{some new id}

Expected behavior
An AuditEvent with the specified id is created and 201 Created is returned.

Actual behavior
The AuditEvent isn't created and a response of 405 Method Not Allowed is returned.

[CaitlinV39]

@CaitlinV39 to review in Zulip

[CaitlinV39]

@tswelsh we are reviewing this with the community. Right now we don't allow creates against the AuditEvent but are curious to see what other FHIR servers are doing. We'll update on a next step after we spend some time gathering feedback. You can see the chat here: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/AuditEvents.20in.20pure.20FHIR.20Servers

[brendankowitz]

Thanks @CaitlinV39.

@tswelsh, I think in principle it makes sense to allow a create with both PUT and POST for AuditEvent.
When using PUT our system immediately checks for the update interaction on AuditEvent which fails.

My summary of the ideal behavior is this:
When CapabilityStatement.rest.resource.updateCreate is true, it should allow creates on PUT and also allow modify when the update interaction (CapabilityStatement.rest.resource.interaction) is also present.

[tswelsh]

Thanks for looking into this! To be clear, our desired behaviour would be to create AuditEvents with a PUT request but not allow editing or deleting, which sounds like something we could do if it matches your ideal behaviour.

[CaitlinV39]

AB#77959