What can a mock help you check before the real API is ready?
A mock is a stand-in for the real service. Give it one reply with available appointments and another that says none are left. You can decide how the same booking page should look in both situations without waiting for the real system or needing real reservations.
How do you keep a local mock separate from a real service?
Use a mock file containing only fictional data. If your team later runs it, confirm the local listener is limited to the computer, any forwarding to a real server is off, and the test copy of the app points only at the mock. Desktop request logging can show headers and bodies, so keep credentials and real details out of requests as well as replies.
What can you save and share with a teammate?
Mockoon desktop keeps an environment in a JSON file with routes and example replies. Save that file when you need another person to reproduce the mock. The tool can also export an OpenAPI description. Keep the native file because the interface description serves a different purpose from a runnable mock.
The open-source desktop and command-line tools are available separately from paid Pro collaboration. Current Pro Team is self-hosted. Managed cloud is an Enterprise option.
How should your page behave when the appointment service is unavailable?
Sketch three fictional replies and the screen that each should produce. This is a design check before anybody runs the mock.
- Show normal and empty statesDraw a reply with two times and one with an empty list. Give each screen a distinct, useful response.
- Show a temporary failureDraw a service-unavailable reply. Decide what the visitor can do next without assuming all times are taken.
- Hand off the examplesWrite the three replies in the handoff so someone implementing the mock knows which state each reply should cause.