Back-End Development
What this domain tests
Back-End Development covers the server side of the stack: designing REST APIs, writing routes and middleware in Node.js/Express or Python frameworks, modelling data in SQL and NoSQL stores, and handling authentication and input validation securely.
Core rules and concepts
- REST: resources are plural nouns (
/orders,/orders/42), behaviour comes from the HTTP method, and the API is versioned (/api/v1/...). - Status codes carry meaning: 200 read, 201 created, 204 no content, 400 malformed request, 401 not authenticated, 403 authenticated but not allowed, 404 missing, 409 conflict, 500 server fault.
- Middleware runs in registration order; the error handler takes four arguments and must be registered last.
- Always validate input at the boundary and use parameterised queries - string-concatenated SQL is the classic injection hole.
- Store passwords only as salted hashes (bcrypt, argon2). Sessions keep state on the server with a cookie holding an ID; JWTs are signed, not encrypted, so never put secrets in the payload.
- Relational databases give ACID transactions and joins; document stores suit flexible, denormalised payloads. Indexes speed reads and slow writes.
Worked example
POST /api/v1/orders with a JSON body. Check the session or token: no credentials → 401. Validate that quantity is a positive integer: invalid → 400 with a field-level message. Insert the order and decrement stock inside one transaction so a failure cannot leave the two out of step, using parameterised SQL. Return 201 with Location: /api/v1/orders/42 and the created object. A later GET /api/v1/orders/99 for a missing row returns 404 - not 400, which would blame the client for a well-formed request.
Traps that cost marks
- Returning 200 with an
errorfield in the body. - Using PUT to change one field - that is PATCH; PUT replaces the resource.
- Returning 403 when the user is simply not logged in (that is 401).
- Leaking stack traces to clients.