APIREST API2025

Vehicle Rental API

Production-ready REST API with JWT auth, Swagger docs, and full test coverage.

Role

Backend Developer

Duration

2 weeks

Year

2025

100%

Type-safe

Full

Test coverage

The Problem

Most REST APIs built in learning contexts cut corners that matter in production - weak authentication, no input validation, untested endpoints, undocumented behavior, and race conditions in booking flows that cause real data problems.

The Vehicle Rental API was built to production standard - every layer secured, validated, tested, and documented.

What I Built

A production-ready vehicle rental backend API. JWT authentication, role-based access control, Zod validation on every input, transactional booking logic with row locking, full Swagger documentation, and comprehensive Jest test coverage.

Selected Screens
Proof of backend depth, not just endpoint volume
This project needed to show more than code snippets. The screens had to prove documentation quality, implementation discipline, and testing rigor across the actual backend workflow.
Screen 01Vehicle Rental API landing page
Vehicle Rental API landing page
Landing section highlighting the backend API and key features.
Screen 02Vehicle Rental API Swagger documentation
Vehicle Rental API Swagger documentation
Interactive OpenAPI documentation and endpoint testing.
Screen 03Vehicle Rental API source code in VS Code
Vehicle Rental API source code in VS Code
Backend source code structure and implementation details.
Screen 04Vehicle Rental API endpoint details
Vehicle Rental API endpoint details
Detailed endpoint-level API documentation from Swagger.
Screen 05Vehicle Rental API test run
Vehicle Rental API test run
Jest test run showing backend coverage and passing suites.

JWT authentication

Secure authentication with bcrypt-hashed passwords, signed JWT tokens, and role-based access checks on every protected endpoint. Tokens expire. Roles are verified server-side, not client-side.

Transactional booking with row locking

The hardest problem in any booking system: preventing double-booking under concurrent load.

Two users attempting to book the same vehicle at the same time is a race condition. The solution is a database transaction with row-level locking - the first request acquires the lock, completes the booking, and releases. The second request waits, then finds the vehicle unavailable.

This is not a theoretical concern. It is the difference between a reliable booking system and one that fails under real usage.

Zod validation

Every request body, query parameter, and route parameter is validated with Zod before it reaches the business logic layer. Invalid input returns a structured error immediately. Nothing malformed reaches the database.

Swagger documentation

The full API is documented with OpenAPI via Swagger - every endpoint, every request shape, every response schema. Explorable interactively in the browser. No guessing how an endpoint works.

Jest test coverage

Authentication flows, vehicle endpoints, booking logic, and middleware - all covered with Jest tests. Tests run in CI. Nothing ships untested.

Security hardening

  • Rate limiting on all endpoints
  • Security headers - Helmet middleware
  • Centralized error handling - no stack traces in production responses
  • Environment-based configuration - no secrets in code

Key Decisions

Row locking over application-level locking.Application-level solutions to concurrency problems are fragile. The database is the right place to enforce booking integrity - it has the primitives for it and they are battle-tested.

Zod over manual validation. Manual validation is verbose, inconsistent, and easy to miss. Zod schemas are declarative, reusable, and automatically generate TypeScript types.

Swagger from the start. Documentation written after the fact is always incomplete. Documenting endpoints as they are built ensures the docs match reality.

The Result

The Vehicle Rental API demonstrates backend engineering depth - not just building endpoints, but building them correctly. Security, validation, concurrency, testing, and documentation are not afterthoughts here. They are the foundation.

Production-ready means more than working. It means working correctly under real conditions, with real users, making real concurrent requests.