Question

Let’s say I have a REST method to update a record. That would obviously be a POST because it’s updating a resource. However in the same motion, a new record in an audit or revision history table needs to be created.

Is there a standard or best practice here, of whether to use POST or PUT?

Does the REST method come from what is happening on the user side, or does it come from what happens in the database?

One possibility is to call just one method, which updates a record in one table and creates a new record in another table.

Another possibility would be to force that the POST only updates one table, and would require an additional method to do a PUT in the audit table. This forces the use of 2 methods and puts the responsibility on the developer, which I’m not too keen on.

Answer 1

PUT is actually recommended for the replacement (update) of an existing record.

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server.

There is also some information about the difference between POST and PUT:

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request — the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource.

See here.

To me it sounds like you should use a PUT request to update the resource. Auditing is a side-effect of doing that, and so it should be handled as part of PUTting the new resource.