Get / Put Strategy When Programming With REST API

I'm creating a custom VB.NET application that accesses our instance using the REST API. I'm wondering if anyone can recommend a general strategy for preventing records from being edited in the time between the custom app GET and PUT calls are made?

I read an article that seems to address this issue called "Optimistic Locking in a REST API", where they perform a Conditional PUT using the HTTP Header / ETag / If-Match..."By specifying the appropriate ETag and condition header, you can perform optimistic locking for concurrent operations on a resource....using the If-Match header during the PUT call. If the ETag header does not match the value of the resource on the server, the server rejects the change with a 412 Precondition Failed error. The client is therefore notified of the error, and can try the request again after updating their local copy of the resource."

Is this possible with how SugarCRM has implemented their REST API?

Is this a typical strategy to check the state of a record prior to a PUT call?

Anyone using RestSharp in Visual Studio and has a solution for this issue?

Anyone else doing something different to check for altered records prior to PUT calls?

Any feedback would be much appreciated.

  • The method available using built-in features would be to request only the modified date field using the record ID. That is a fast request due to the indexed ID column and the return of a single field. If the date modified changed since the original GET then there needs to be a strategy to deal with that in the tool that is using REST. 

    A possible alternative would be to extend Sugar to add a file locking method. The full scope of that is not something I have seen implemented so far. I do see the the needed parts exist. The scope of the project would be non-trivial.

    This code example explains how to add file locking by extending ACLs.

    SugarCRM v7 - Conditional record locking through ACL's customisation · GitHub 

    It would be important to have a tool in Sugar to check for stale locks and unlock them either manually or automatically based on age. It's possible the PUT to lock the file could write a timestamp specifying the lock timeout.

    The steps would then be PUT (lock), GET (for edit use), PUT (for save and include the unlock in this).

    Or for strict use PUT (lock), GET (for edit), PUT (save), GET(verify write), and finally PUT (unlock). 

    The strict process seems overkill though, as a PUT does include a response that should confirm write.