Scenario
Workspace/Tenant Isolation
Create two workspaces, add items to each, and confirm the API keeps them completely separate — items in one never leak into the other, and an unknown workspace id 404s instead of returning an empty list.
How this works
- · Every resource carries a workspaceId, and every read/write is filtered by it — that filter is the entire isolation mechanism, no cookies involved.
- · Two workspaces created back-to-back are fully independent: adding an item to one never shows up when listing the other, even though both live in the same shared in-memory store server-side.
- · Querying an unknown workspace id returns 404, not an empty array — the API deliberately distinguishes "this workspace has zero items" from "this workspace doesn't exist," which is exactly the distinction real multi-tenant test suites need to get right.
What you'll practice
- A resource-scoped isolation model — the workspace id in the URL IS the isolation boundary, not a cookie
- Items added to workspace A never appear when listing workspace B, even though both exist in the same shared store
- Querying a workspace id that doesn't exist returns 404, not an empty list — the API distinguishes "exists but empty" from "doesn't exist"
- This is the actual pattern real frameworks use for parallel-safe tests: spin up a fresh scoped sandbox per test, work inside it, discard it
API reference
POST /api/scenarios/workspaces
body { name } → { workspace: { id, name } } (201)
GET /api/scenarios/workspaces/:workspaceId/items
scoped entirely to that workspace — 404 if the workspaceId doesn't exist
POST /api/scenarios/workspaces/:workspaceId/items
body { title } → { item } (201), or 404 if the workspaceId doesn't exist
curl -X POST https://playground.krishanchawla.com/api/scenarios/workspaces -H "Content-Type: application/json" -d '{"name":"Team A"}'
curl -X POST https://playground.krishanchawla.com/api/scenarios/workspaces/<workspaceId>/items -H "Content-Type: application/json" -d '{"title":"First item"}'
- 1 Console