Playground API
Stop Waiting for the Backend • Part 3 of 124 min read•2026-02-21

What If Your Mock API Actually Remembered Your POST Requests?

Discover what happens when a mock API remembers your HTTP POST, PATCH, and DELETE requests per browser session, transforming frontend testing and prototyping.

NK
Nilesh Kumar
Creator of Playground API
What If Your Mock API Actually Remembered Your POST Requests?

What If Your Mock API Actually Remembered Your POST Requests?

Suggested URL Slug: mock-api-remember-post-requests

Primary Keyword: stateful mock API

Secondary Keywords: mock API post request, frontend prototype state, mock backend testing, REST API sandbox

Meta Description: Discover what happens when a mock API remembers your HTTP POST, PATCH, and DELETE requests per browser session, transforming frontend testing and prototyping.

Suggested Dev.to Tags: #javascript, #react, #webdev, #testing

Imagine you go to a restaurant. You sit down, look at the menu, and order a cup of coffee. The waiter writes down your order, smiles, and says, "Order received! Your ticket number is 42."

Two minutes later, the waiter returns with an empty tray. When you ask where your coffee is, the waiter looks puzzled and says, "Oh, we acknowledge orders, but we don't actually make them. If you check our menu, it is still the same as when you walked in."

If this happened in real life, you would leave the restaurant. Yet, as frontend developers, we deal with this exact scenario daily when prototyping against mock APIs.

We send a POST request to create a record. The server returns a status code of 201 Created. But the moment our app navigates back to the dashboard or queries the collection, the server completely forgets that the request ever happened.

What if your mock API actually remembered your requests?

The Illusion of Memory in Frontend Prototyping

When testing frontend applications, there are three common workarounds developers use to fake backend memory:

  1. Local Component State (useState / Pinia / Vuex):

You store mock data in client-side arrays. Every time you refresh the page or open a new browser tab, all your modifications reset to initial mock constants.

  1. localStorage / IndexedDB Mocks:

You write custom adapter wrappers that save items to localStorage. While this persists across reloads, it does not test actual HTTP serialization, headers, HTTP status codes, or asynchronous server latency.

  1. Disposible Local Servers (json-server / Express):

You run a local server file on your machine. This works, but it cannot be easily shared with team members, designers, or QA testers reviewing your pull request deployment on Vercel or Netlify.

None of these approaches deliver the experience frontend engineers actually want: a live, hosted cloud API that remembers mutations per session without requiring local database setup.

What "Stateful API Mocking" Looks Like in Action

A stateful mock API bridges the gap between static dummy JSON and full production backends. It functions by creating an isolated sandbox for your browser session.

Here is the exact lifecycle:

mermaid
1
sequenceDiagram
2
autonumber
3
actor Dev as Frontend Client
4
participant API as Playground API Sandbox
5
6
Dev->>API: 1. POST /posts { title: "New Feature Launch" }
7
API-->>Dev: 201 Created { id: 101, title: "New Feature Launch" }
8
9
Note over API: Stored in callers Virtual Session Overlay
10
11
Dev->>API: 2. GET /posts/101
12
API-->>Dev: 200 OK { id: 101, title: "New Feature Launch" }
13
14
Dev->>API: 3. PATCH /posts/101 { title: "Updated Title" }
15
API-->>Dev: 200 OK { id: 101, title: "Updated Title" }
16
17
Dev->>API: 4. DELETE /posts/101
18
API-->>Dev: 200 OK { message: "Resource deleted" }
19
20
Dev->>API: 5. GET /posts/101
21
API-->>Dev: 404 Not Found

Every standard HTTP verb functions exactly as it would on a production server:

  • POST → GET: Newly created records immediately appear in collection lists and single-resource queries.
  • PATCH / PUT → GET: Updated fields reflect on subsequent queries.
  • DELETE → GET: Deleted items return 404 Not Found and are excluded from pagination counts.

Step-by-Step Code Walkthrough

Let's test this directly against Playground API by Niles Labs. You can run this directly in your browser console or Node.js environment:

javascript
1
const BASE = 'https://playground.nileslabs.com/api/v1';
2
3
async function runStatefulDemo() {
4
// Step 1: Create a Todo item
5
console.log('--- 1. Creating a Todo ---');
6
const createRes = await fetch(${BASE}/todos, {
7
method: 'POST',
8
headers: { 'Content-Type': 'application/json' },
9
body: JSON.stringify({
10
title: 'Review PR #204',
11
completed: false,
12
user_id: 1,
13
}),
14
});
15
const createdTodo = await createRes.json();
16
console.log('Created:', createdTodo);
17
18
// Step 2: Retrieve the newly created Todo by ID
19
console.log('\n--- 2. Fetching Created Todo by ID ---');
20
const getRes = await fetch(${BASE}/todos/${createdTodo.id});
21
const fetchedTodo = await getRes.json();
22
console.log('Fetched:', fetchedTodo);
23
24
// Step 3: Toggle the completion state via PATCH
25
console.log('\n--- 3. Updating Todo via PATCH ---');
26
const patchRes = await fetch(${BASE}/todos/${createdTodo.id}, {
27
method: 'PATCH',
28
headers: { 'Content-Type': 'application/json' },
29
body: JSON.stringify({ completed: true }),
30
});
31
const updatedTodo = await patchRes.json();
32
console.log('Updated Status:', updatedTodo.completed); // true
33
34
// Step 4: Delete the Todo
35
console.log('\n--- 4. Deleting the Todo ---');
36
const deleteRes = await fetch(${BASE}/todos/${createdTodo.id}, {
37
method: 'DELETE',
38
});
39
console.log('Delete status:', deleteRes.status); // 200
40
41
// Step 5: Verify it is gone
42
console.log('\n--- 5. Verifying Deletion ---');
43
const verifyRes = await fetch(${BASE}/todos/${createdTodo.id});
44
console.log('Status on deleted item:', verifyRes.status); // 404 Not Found
45
}
46
47
runStatefulDemo();

Multi-Tab & Multi-Client Session Isolation

A common question is: If multiple developers or automated test suites use the API simultaneously, will their POST requests overwrite each other?

No. Stateful sandbox engines use session isolation:

  • In Browser: An HTTP-only session cookie automatically identifies each browser sandbox.
  • In CI/CD & Automated Tests (Playwright / Cypress): You can pass a custom header X-Playground-Identity: test-runner-suite-1 to maintain an isolated sandbox across parallel test runners.
  • Resetting State: Whenever you want a clean slate, a simple DELETE /session/reset request flushes your session overlay and restores the default seed dataset.

Why This Changes Frontend Development

When your mock API behaves like a real backend:

  1. Interactive Client Demos Work: You can send a live preview link (e.g. on Vercel) to stakeholders or clients, and they can click around, create posts, toggle todos, and delete items without finding broken empty states.
  2. Realistic Query Invalidation: Tools like React Query, SWR, and Redux Toolkit Query behave naturally when invalidating query caches.
  3. No Database Maintenance: You spend zero minutes configuring Docker, spinning up Postgres instances, or writing migration scripts for throwaway prototypes.

Conclusion

Mock APIs should do more than echo your requests. By remembering mutations across the entire HTTP lifecycle, stateful sandboxes make frontend prototyping feel authentic and production-ready from the very first commit.

To experiment with persistent mutations in your next application, start testing with Playground API by Niles Labs.

Tags:#javascript#react#webdev#testing
Series: Stop Waiting for the Backend
Part 3 of 12
Previous Article (#2)
Why Static Mock APIs Aren't Enough for Modern Frontend Development
Next Article (#4)
How to Test API Error States in React Without a Real Backend

Try Playground API in Your Own App

Stateful mock REST & GraphQL API with private sandbox overlays.

Quickstart GuideOpen Interactive Studio