If the same request returns different data during different invocations, replayer has no way of differentiating between the two invocations. This can happen when, for example, a resources is fetched using a GET request, it is modified using a PUT request, and it is fetched once more using a GET request to verify that it was updated successfully.
One could add an option to replayer that enumerates the identical requests: It would count how often each request hash has occurred and store fixtures including their number.
As an example, let's assume that GET /foo's hash is abc123 and PATCH /foo … isdef456`, and we do three requests:
GET /foo
PATCH /foo …
GET /foo
There would now be three fixtures:
abc123-1
def456-1
abc123-2
Of course, this wouldn't work in every use case, but AFAICT it solves all basic "read, modify, read again" use cases.
One could add an option to replayer that enumerates the identical requests: It would count how often each request hash has occurred and store fixtures including their number.
As an example, let's assume that
GET /foo
's hash isabc123
andPATCH /foo … is
def456`, and we do three requests:GET /foo
PATCH /foo …
GET /foo
There would now be three fixtures:
abc123-1
def456-1
abc123-2
Of course, this wouldn't work in every use case, but AFAICT it solves all basic "read, modify, read again" use cases.