Handling duplicate requests in REST api

Sometimes the REST call committed successfully on the server, but the communication channel broke and a 500 error occurs. You may think that the server rolled back the transaction and resend the request. This in some cases can result in erroneous or duplicate data. To avoid this situation, the REST API framework provides a mechanism to catch this double-dipping issue. The request for create/update/delete can contain a request header called transactionid where the API framework validates for duplication. If no matches are found, the transaction is good to go. If a match is found, the request is rejected with a HTTP 409 Conflict error.

Note that the transactionid header value is user generated and hence is the responsibility of the client code to make sure it is unique enough that is does not clash with another valid request. If the server does not find a match, it stores it as part of the request transaction commit so that in can reject future transactions with the same transaction id. The default life of the transaction ID is five minutes, controlled by the escalation OSLCTXN. However, this can be modified as per the installation need.

Note that this feature is primarily useful when you are operating the REST client in an asynchronous or disconnected mode (much like the Anywhere platform). This feature may not make much sense for in the connected/interactive mode.