The REST API is identical to the SOAP API in terms of basic functionality. The only major difference is the lack of "bulk" processing capabilities as you'd find in the SOAP API (e.g. passing in a list of 200 records to be processed at once), as well as differences to describe calls, the way headers are formatted, etc, all of which are presentation differences as opposed to actual differences in system logic.
In other words, the system basically respects the same settings that the SOAP API does. Notably, it does not respect read-only fields at the page layout/record type level, just like the SOAP API does not, but it does honor read-only and universally required fields as specified at the database level. It also runs standard and custom validation rules, uniqueness constraints, workflow rules, headless flows, triggers, owner change notifications, roll-up summary updates, and obeys the sharing model for queries, updates, and deletes, just as it would in the UI.
You must code your applications to expect the possibility that a user will receive some validation error while trying to update the record. You should also generally take advantage of the describe calls and UserRecordAccess object to present the appropriate standard buttons (edit, delete), but the system will protect those records and fields anyways if you choose not to perform access checks ahead of time and/or the settings change. You don't have to "do anything" special to actually get the system to protect the records, objects, and fields that should be protected.