Frontend API mocking workflow

Purpose

Ship frontend screens and interaction logic with reliable local API behavior.

Where this is used

• Early UI development before backend endpoints are finished.
• QA reproduction with fixed responses.
• Demo environments where live backend access is restricted.

Setup and prerequisites

• Create a local server and choose fallback strategy (`STRICT` or `FALLBACK`).
• Add at least one endpoint in `MOCK` mode for each frontend-critical route.
• Point frontend base URL to the running Mockphine server URL.

Step-by-step workflow

1. Create a server with `STRICT` fallback to expose missing route coverage immediately.
2. Add endpoints for core views (`GET` lists, `POST` create, etc.).
3. Start the server and run frontend locally.
4. Trigger UI flows and inspect requests in Live View.
5. Patch endpoint body/status/delay settings as UI requirements change.
6. When backend is ready, switch specific routes to `PASSTHROUGH` as needed.

Expected result and output

• Frontend requests resolve against predictable local responses.
• Live View shows `served-by = mock` for routes still mocked locally.
• Missing routes surface as `strict_404` when fallback is `STRICT`.

Common issues and fixes

• Frontend still hits remote API: verify the app environment points to Mockphine local URL.
• Unexpected `strict_404`: add missing endpoint or adjust method/path/query mode.
• Unexpected passthrough: check endpoint mode and server fallback mode.

To tune matching details, continue withRequest matching and routing.