Working with POST requests and mocks
The purpose of the mocked back-end is to validate that the POST request sent is correct. The assumption is that if the POST request from the front-end (or API) is correct, then it is the responsibility of the provider API developer to validate that the provider service works correctly. Mesh Dynamics provides the ability to review the POST request, as well as compare it against earlier requests to identify any changes.
Since there isn't a real service when a POST API is mocked, there is no actual data update. When the back-end is mocked, POST requests will not actually update any data.
What does this mean for the developer using mocked POST request APIs?
API developers are usually used to using mocks for the provider APIs. They typically send requests one at a time, and review the results of individual requests. There is no dependence across the requests.
The same process is also applicable to front-end developers. Front-end developers must first ensure that they are sending the right requests to the back-end, and that can be achieved using Mesh Dynamics.
However, front-end developers cannot validate user flows that involve changing data, and then using the updated data as part of the user flow. This functionality requires live databases, and cannot be validated using API mocks. For example, you cannot expect to send a request from the front-end to update an address, and expect subsequent requests to reflect the updated address.