With a communications medium that is not 100% reliable, requests and responses can be lost.  Communications protocols that require reliability must support a RetryMechanism whereby a client can re-attempt a transaction for which it did not receive a response.

For operations that are not idempotent, it is important to ensure that the operation is performed exactly once.  If the server receives a request and performs the operation, but the client does not receive the response, then the client may retry the request.  The server must not perform the operation again, but must return a suitable response.

'''Therefore,'''

Attach a SequenceNumber to each request.  If the server receives a request from a client with a sequence number it has already processed, then it can simply re-send the previous response, or send a response that means "this request has been processed".

Sequence numbers also provide a way to match up responses with requests if a client can have multiple transactions in progress simultaneously.

'''But,'''

Beware of initialization, overflow, and boundary conditions with sequence numbers.

----

''Someone at work was telling me that this is an AntiPattern, but couldn't explain what was wrong with it or what a better solution is.  Can anyone around here provide some criticism?''

Maybe they wanted all protocols to be stateless or idempotent, which is a good goal,
but is often not possible. So it is not an AntiPattern, but you need to try
not to need it. I have made some very big mistakes this by not following this
advice.

----
See also ChangeNumber