If two clients PUT the same resource (such as a goal with its many fields) simultaneously, one of the two will win and overwrite the earlier update. The earlier changes will be lost completely and there is no easy way for either client to be notified of this.
Optimistic Locking is one way to address this: The client provides together with the update the timestamp of the resource’s last known update and the server only performs the update if this supplied timestamp equals the resource’s most recent update. If they don’t equal, the server knows that the resource was updated unbeknownst to the client and can indicate this via a HTTP status code.
IMHO this is well suited for Beeminder for a number of reasons, one of them being that most resources already provide this timestamp, such as the goal and user resource with their updated_at field.
The other reason being that the Beeminder server sees low data contention, presumably.
Alternatively, the API could use an HTTP ETag, which is basically the same thing, just as HTTP header.
Ruby on rails does support optimistic locking out of the box: https://api.rubyonrails.org/classes/ActiveRecord/Locking/Optimistic.html
On the chance that Beeminder does already offer optimistic locking: Why is it neither documented nor mandatory?
Thoughts? @bee