The problem with "dumb" mocks
Traditional mock rules always return the same response: GET /users always returns the same 3 users. POST /users creates a record in memory... until the server restarts. That's fine for testing a static screen, but it falls apart when you need to test complete flows.
What if the mock behaved like a real database — creating, reading, updating and deleting records with persistence between requests?
POST /products
{name: "Shoes", price: 299}
{name: "Shoes", price: 299}
→
httpdrop CRUD
persistent SQLite
persistent SQLite
→
201 Created
{id: 1, name: "Shoes"}
{id: 1, name: "Shoes"}
What auto CRUD generates
When you create a CRUD table for the path /products, httpdrop automatically provides:
MethodRouteWhat it does
GET/productsList with pagination and filters
POST/productsCreates record, returns 201
GET/products/:idFind by ID
PUT/products/:idReplace full record
PATCH/products/:idPartial field update
DELETE/products/:idDelete record
Filters and pagination built in
Query string examples
GET /products?_page=2&_limit=10 GET /products?category=electronics GET /products?price_gte=100&price_lte=500 GET /products?_sort=name&_order=asc
Real-world use cases
Mobile app — Build the complete app while the backend doesn't exist yet. Test create, edit and delete flows with real persisted data.
Prototype and demo — Show a fully functional demo to stakeholders without needing a server, database or deployment.
Integration tests — Isolate the service under test using a mock API with real state. No fixtures, no complicated seed scripts.
Teaching and bootcamps — Students learn to consume REST APIs with real data without setting up a backend, database or authentication.
Auto seed: Use Faker tokens to populate the table with realistic synthetic data (names, emails, addresses) in one click — perfect for demos and testing.