Stop scripted REST API from updating fields after certian state (change API)

[Janel]

We're trying to implement the OOB scripted REST APIs for change, but we're running into a snag with writable fields.

The OOB API (/api/sn_chg_rest/v1/change), which I'm sure is true of any of the APIs, allows clients to update fields after a change is submitted that shouldn't be updated.  For example, Justification can be written to while only in the New state.  This can still be written to via APIs even while the state is not New.

There is a UI policy controlling what cannot be updated from the UI, so obviously that won't apply to the APIs.

What is the best method to control when an API can write to a field at a specific state?  Field ACLs (which sounds like a nightmare)?  Data policies?  State model transitions?

The one snag we are running into is that a change_manager should be able to update any field at any state, and I'm guessing that throws the data policy idea right out the window.

[Akshay14]

We ran into similar problem in the past and came up with tow solutions. 

1. Exposing OOTB APIs directly to the change table will always have many challenges like you're facing, therefore one can create a staging table and expose API's for staging table. Once data is submitted into staging table, you can process that into target table with greater control(We can write business login on staging table).

2. Create custom scripted REST APIs instead of OOTB table APIs so that you can analyzed the payload before making updates to change table and also send any error response immediately if your payload does not qualify updating data on change table. We went ahead with this option. 

Hope this helps.