A mock API answers requests the way a real service would — same URLs, same status codes, same response shapes — without any of the system the real one depends on. It exists so that a client can be built, demonstrated or tested before the real service is ready, or when calling the real one would be slow, expensive, rate-limited or destructive.
Mocks come in three broad shapes. A static mock always returns the same canned payload. A configurable mock lets you declare, per endpoint, what to return. A simulated mock — which is what this playground is — actually keeps state: a POST creates something a later GET can find, a DELETE removes it, and constraints such as stock levels, seat availability and version conflicts are enforced rather than described.
The common assumption is that a mock cannot exercise error handling, because a mock always succeeds. That is a property of most mocks, not of mocking. It is precisely the failure paths — 409, 412, 429, 503 — that are hardest to provoke against a real service and most valuable to rehearse, which is why an API that only ever returns 200 makes for a weak practice target.
Every API here runs both ways: entirely in your browser with no network at all, or against a live backend over HTTPS. The browser engine is the same code, so the responses match.
All glossary terms · Testing techniques · All 39 mock REST APIs