Mock REST API with Fake Users, Posts and Todos

What is a mock API?

A mock API is a stand-in for a real backend: it answers HTTP requests with realistic, predictable JSON so you can build and test the code that calls an API before the real one exists, without credentials, or without touching production data. Frontend developers use one to wire up lists, detail pages and forms; people learning fetch, axios or React Query use one so the only moving part is their own code; test suites use one for fixtures that never change.

This one is a read-only fake REST API in the style of JSONPlaceholder. It serves five resources — 30 users, 100 posts, 100 todos, 200 comments and 50 products — generated from a seeded random generator, so /api/mock/users/1 returns exactly the same record on every request, every day. Relationships are consistent: every post and todo has a userId between 1 and 30, and every post has two comments (postId 1 owns comments 1 and 2).

Endpoints, pagination and filtering

Lists: GET /api/mock/{resource}. A list returns at most 100 records; use _page and _limit to paginate (GET /api/mock/posts?_page=2&_limit=10 returns posts 11 to 20). _limit above 100 is capped at 100, and a page past the end returns an empty array rather than an error. Each list response carries the total number of matching records in an X-Total-Count header and first, prev, next and last URLs in a Link header, both exposed to browsers through CORS.

Single records: GET /api/mock/{resource}/{id} returns the record, or a 404 with a JSON error body when the id does not exist — useful for testing your not-found handling. Filters: posts?userId=1, todos?userId=1 or todos?completed=true, comments?postId=1 and products?category=books narrow a list by exact match before pagination.

Writes: POST /api/mock/{resource} returns your JSON body with a new id and 201 Created; PUT returns the body as the replacement record; PATCH returns the existing record merged with your fields; DELETE returns 200 and {}. Bodies must be a JSON object of at most 32 KB, otherwise you get a 400 or 413, which makes the API handy for testing validation errors too.

Use it with fetch, axios, Postman and in tests

fetch: const users = await fetch('https://techloghub.com/api/mock/users').then(r => r.json());

Create a post with fetch: await fetch('https://techloghub.com/api/mock/posts', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ title: 'Hello', userId: 1 }) }) — the response is the created object with id 101.

axios: const { data, headers } = await axios.get('https://techloghub.com/api/mock/todos', { params: { userId: 3, _limit: 5 } }); headers['x-total-count'] holds the total for building a pager.

curl: curl -i 'https://techloghub.com/api/mock/products?category=audio'.

Postman or Insomnia: paste any endpoint URL into a new request; no auth or API key is needed. In automated tests, the fixed data lets you assert on exact values (users/1 always has the same name and email), and the 404, 400 and 413 responses cover error paths. For tests that must run offline or in CI without network access, keep a copy of the responses you need as local fixtures or use a request-mocking library such as MSW instead.

Limitations

Nothing you send is stored. A POST returns a new id but a following GET for that id is a 404; a PATCH or DELETE does not change what the next GET returns. That is deliberate — the API is shared by everyone, so it behaves the same for every caller, and the data effectively resets on every request.

There is no search, sorting or nested route such as /posts/1/comments (use comments?postId=1), no authentication to test against, and write requests are rate limited per IP address. The data is generated filler, not real people or products. For a persistent fake backend you control, run json-server locally against your own db.json.