Support for Different Sequential Responses to the Same Request

[daniel-klingensmith-jamf]

Could we add a feature where if the same resource definition is hit X number of times we can reply with a separate response? I was thinking the mock resource definition would look something like the following:

  - method: GET
    path: "/licenses"
    queryParams:
      accountId: "1001"
    responses:
        response:
          responseNumber: 1
          httpStatus: 404
        response:
          responseNumber: 2
          file: 1001.json

With the above pattern we might continue to return the same response for all future requests after the first. If someone wanted the same response for the first 4 requests we might see:

    responses:
        response:
          responseNumber: 1
          httpStatus: 404
        response:
          responseNumber: 5
          file: 1001.json

To help migration, we could continue to support the single response schema. An endpoint to reset the counter for all resources or individual resources would be vital to help support this pattern as well.

Let me know what you think @outofcoffee!

[outofcoffee]

Hi @daniel-klingensmith-jamf, thanks for the suggestion.

It should be possible to achieve this using stores.

Note As an aside, bear in mind that any implementation is going to have to cater for concurrent requests, and any potential race conditions depending on your circumstances.

An approach using stores might look like this:

• Add a script to a resource or interceptor that reads and updates a store, such as requestCount
• You could initialise the value in the store using the preloading feature, or handle the absence of a value in the store as 0 in your script
• In your resources, you could have two different conditions that match on the value in the store - each would return a different response
• To reset the store, either use the built in store API under /system/store or optionally add a custom resource with a script that updates the value in the requestCount store to zero

Keen to know you get on. Best of luck!

[daniel-klingensmith-jamf]

Yeah, stores with scripts seems like the solution I was looking for. Thank you!