It is possible to get updates for an object when the user changes a property. For example, if the user selects a problem on a work order, the server might automatically populate task, supervisor, priority, and other information based on that selected problem. These updates are done using a $nonpersistent specification in the url.
For example, if the user is editing an existing work order with the Autonumber 123, the client application can make this request
PUT http://restapi.gbams.net/gbaMS/Work/WorkOrders.svc/123/$nonpersistent?Property=ProblemCode
And include the current state of the request object in the body of the request. When the server receives this request, it will populate all of the relevant data based on the state of the object provided and will return the updated object to the client without persisting any data to the database.
Additionally, responses from the $nonpersistent request include a property "BrokenRulesDisplayString" which will contain a user friendly message which lists all of the current validation problems on the object. For example, if the user has not yet provided a start date and the start date is a required field, the BrokenRulesString will include a note about the missing data.
Another property returned is PropertiesThatAreDynamicallyReadonly. Sometimes the state of an object will affect which properties on an object are editable. For example, on work orders if a user says they want to use resource costing, the system will not allow the user to input manual task cost information (because it will be rolled up from the resource). It is important to note that the REST API will not throw an exception if the user edits this information, but it will ignore any data provided in these fields which may be confusing to an end user if they were allowed to input data.
Only properties which have AffectsOtherProperties = true will benefit from this. See $fields metadata in this document for how to determine which properties have this attribute.