beginner · review

Review: The /createUser API

A new internal API is up for review before partners integrate; the author says it's “basically REST”. QA reports that reloading a browser tab deleted a test user.

Evidence

POST /createUser            {"name": "...", "email": "..."}  -> 200 {"success": true}
GET  /getUser?id=42          -> 200 {user...} | 200 {"success": false}
POST /deleteUser?id=42       -> 200 {"success": true}
GET  /deleteUserFast?id=42   -> 200  (added "for the admin panel")

Auth: none yet ("internal")   Errors: always HTTP 200, check body.success

Investigate

Inspect Method semantics

`GET /deleteUserFast` mutates state on a safe method — a crawler, prefetcher, or browser reload can delete users; QA's tab reload did exactly that.

Inspect Error contract

Everything returns HTTP 200 with `success: true/false`, so monitoring sees 0% errors, caches may store failures, and clients must parse bodies to detect any problem.

Inspect Resource model and naming

Verb-endpoints (`/createUser`, `/getUser`, `/deleteUser`, `/deleteUserFast`) duplicate what methods already express and have started multiplying — two delete variants with unclear differences.

Inspect Authorization

No authentication or per-resource authorization at all; “internal” is carrying the entire security model.