Node HTTP API.

Ein nachvollziehbarer Weg vom Request zu den Daten.

Die Node HTTP Users API ist eine JavaScript-API zur Benutzerverwaltung. Sie basiert auf Node.js' nativem HTTP-Modul und kommt ohne Webframework aus. Sie verbindet Lese- und Schreiboperationen mit Validierung und SQLite-Persistenz.

Klare Zuständigkeiten in kleinen Modulen.

Der Server startet den Ablauf. Die Anwendung koordiniert CORS, Request-Limit und Fehlerbehandlung; die Routen delegieren Validierung und Datenzugriff.

Vom Server bis zu SQLite, mit klaren Grenzen.

Schreibablauf: server.js → app.js → users-routes.js → Validator → Repository → SQLite. utils/http.js liest JSON-Bodies, prüft Content-Type, setzt CORS und sendet Antworten.

src/
├── server.js
├── app.js
├── routes/users-routes.js
├── validators/user-validator.js
├── repositories/user-repository.js
├── database/
│   ├── database.js
│   └── reset-database.js
├── utils/
│   ├── http.js
│   └── rate-limiter.js
└── errors/
    ├── validation-error.js
    ├── conflict-error.js
    ├── unsupported-media-type-error.js
    ├── payload-too-large-error.js
    └── too-many-requests-error.js

test/
├── users-api.test.js
├── user-validator.test.js
└── rate-limiter.test.js

Das Repository enthält Docker Compose für API und Caddy sowie ein Volume für die SQLite-Datei. Laut README läuft die Anwendung auf einer VM in der Oracle Cloud Infrastructure; Caddy stellt HTTPS bereit.

Verhalten der Demo: reset-database.js löscht alle Benutzer und legt alle fünf Minuten Portfolio Demo neu an. Das Volume speichert die Datei dauerhaft, die Benutzerdaten werden jedoch absichtlich regelmäßig zurückgesetzt.

Implementierte Routen für Benutzer.

Die folgenden Routen sind in users-routes.js implementiert. Die Statuscodes zeigen die jeweilige Standard-Erfolgsantwort; nicht vorhandene Ressourcen liefern 404.

CORS-Preflight wird vor dem Routing beantwortet: OPTIONS liefert 204. Nicht erlaubte Methoden liefern 405 mit einem Allow-Header.

Einen Benutzer per JSON anlegen.

POST /users
Content-Type: application/json

{
  "name": "Davi",
  "email": "davi@example.com",
  "age": 18
}

HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": 1,
  "name": "Davi",
  "email": "davi@example.com",
  "age": 18
}

Das Format entspricht dem README und dem Rückgabewert des Repositorys. SQLite vergibt die id; ihr Wert hängt vom aktuellen Datenbestand ab.

Klare Regeln mit eindeutigen HTTP-Statuscodes.

Die Regeln stehen in user-validator.js und http.js; app.js behandelt Fehler zentral.

21 native Tests in drei Dateien.

Die Suite nutzt node:test und node:assert. HTTP-Tests starten einen echten Server auf einem temporären Port und senden Requests mit fetch; Datentests verwenden eine SQLite-Datenbank im Arbeitsspeicher.

Die HTTP-Suite prüft POST/GET, PATCH und DELETE. PUT ist implementiert, hat aber keinen eigenen Integrationstest. Der Limiter wird als Funktion getestet, nicht über eine HTTP-429-Antwort. Ein Coverage-Bericht ist nicht eingerichtet.

Keine externen npm-Abhängigkeiten.

Benötigt wird eine Node.js-Version mit node:sqlite (das Docker-Image des Projekts nutzt Node 26). Da keine npm-Runtime-Pakete eingetragen sind, ist zum Start keine Abhängigkeitsinstallation erforderlich; npm start hört standardmäßig auf http://localhost:3000.

git clone https://github.com/davi-amaraldev/node-http-users-api.git
cd node-http-users-api
npm start

Tests ausführen

Linux / macOS: npm test
PowerShell: $env:NODE_ENV='test'; node --test

Den Weg von HTTP bis zur Persistenz nachvollziehen.

Das Projekt zeigt praktische Arbeit mit Methoden, Headern, Statuscodes, Body-Parsing, Validierung, parametrisierten SQL-Abfragen und Tests auf mehreren Ebenen. Statt eine fertige CRUD-Abstraktion zu verwenden, bestand die Übung darin, die einzelnen Schritte zu strukturieren und zu erklären, wie ein Request gespeicherte Daten erreicht und als Response zurückkommt.