camelCase vs. snake_case: Welche JSON-Feldnamen sind besser?

Im architektonischen Design verteilter Systeme sind APIs nicht nur Kanäle für die Systeminteraktion; sie sind Verträge, die verschiedene Tech-Stacks, Organisationskulturen und sogar Entwicklungszeiten miteinander verbinden. Innerhalb der Design-Details von RESTful APIs entfacht ein scheinbar kleines Thema endlose Debatten: Sollten JSON-Feldnamen camelCase oder snake_case verwenden?

Dies ist nicht nur eine ästhetische Wahl. Es berührt die „Impedanzanpassung“ zwischen Backend-Persistenzschichten und Frontend-Präsentationsschichten, betrifft die Serialisierungsleistung, die Effizienz der Netzwerkübertragung, die Developer Experience (DX) und die kognitive Psychologie.

Basierend auf der Geschichte der Programmiersprachen, den zugrunde liegenden technischen Implementierungsmechanismen und den architektonischen Entscheidungen von Branchenriesen wie Google und Stripe, bietet dieser Artikel einen Expertenleitfaden für Entscheidungen.

1. Historische Ursprünge: Eine semiotische Wahl

Um diese Debatte zu verstehen, müssen wir die Entwicklung der Computersprachen zurückverfolgen. Namenskonventionen entstanden nicht aus dem Nichts; sie sind Produkte von Hardwarebeschränkungen und Gemeinschaftskulturen bestimmter Epochen.

Der Ursprung von snake_case: C und die Unix-Philosophie

Die Popularität von snake_case (z.B. user_id) reicht bis in die 1970er Jahre zurück, zu C und Unix. Obwohl frühe Tastaturen (wie das Teletype Model 33) Umschalttasten hatten, waren viele frühe Compiler nicht zwischen Groß- und Kleinschreibung zu unterscheiden. Um Wörter auf Bildschirmen mit niedriger Auflösung klar zu unterscheiden, führten Programmierer den Unterstrich ein, um Leerzeichen in der natürlichen Sprache zu simulieren. Diese Gewohnheit wurde tief in den SQL-Datenbankstandards verwurzelt. Bis heute ist der Standard-Spaltennamenstil für PostgreSQL und MySQL snake_case, was die Grundlage für die zukünftige Abbildungsreibung zwischen APIs und Datenbanken legte.

Der Aufstieg von camelCase: Die Hegemonie von Java und JavaScript

camelCase (z.B. userId) entstand mit der Objektorientierten Programmierung (Smalltalk, C++, Java). Java etablierte den Industriestandard „PascalCase für Klassen, camelCase für Methoden/Variablen“. Der entscheidende Wendepunkt war die Geburt von JavaScript. Obwohl JSON aus JS-Objektliteralen entstand, übernahm die JS-Standardbibliothek (z.B. getElementById) durchgängig camelCase. Als AJAX und JSON XML als dominante Datenaustauschformate ablösten, erlangte camelCase im Web-Bereich einen „nativen“ Status.

2. Kernkonflikt: Impedanzanpassung von Tech Stacks

Wenn Daten zwischen verschiedenen Sprachen fließen, stoßen sie unweigerlich auf eine „Impedanzanpassung“.

Die Backend-Perspektive (Python/Ruby/SQL)

Im Backend empfehlen die Python (PEP 8) und Ruby Communities dringend snake_case.

• Python/Django/FastAPI: Ihre Pydantic-Modelle entsprechen normalerweise direkt den Datenbanktabellenstrukturen:

class UserProfile(BaseModel):
    first_name: str  # Python-Konvention
    last_name: str

Wenn die API camelCase vorschreibt, müssen Sie Aliase oder Konverter in der Serialisierungsschicht konfigurieren. Obwohl dies machbar ist, fügt es eine Schicht von Abbildungslogik hinzu.

• SQL-Datenbanken: Die meisten Datenbankspaltennamen verwenden snake_case. Wenn die API camelCase verwendet, muss die ORM-Schicht die Konvertierung konsistent handhaben.
• Stripe's Wahl: Der Grund, warum Stripe und GitHub sich fest für snake_case entschieden haben, liegt größtenteils darin, dass ihre frühen Architekturen auf dem Ruby-Stack aufgebaut waren. Das direkte Exponieren interner Modelle gewährleistete die Backend-Konsistenz.

Die Frontend-Perspektive (JavaScript/TypeScript)

Im Browser ist camelCase der absolute Herrscher.

• Fragmentierung des Codestils: Wenn eine API snake_case zurückgibt, wird der Frontend-Code inkonsistent:

const user = await fetchUser();
console.log(user.first_name); // Verletzt ESLint camelcase-Regel
render(user.email_address);

ESLint wird dies als Warnung kennzeichnen und Entwickler zwingen, die Regel zu deaktivieren oder Daten sofort nach Empfang zu konvertieren.

• Destrukturierungs-Problem: In der modernen JS/TS-Entwicklung ist die Objektdestrukturierung allgegenwärtig. Wenn Felder snake_case sind, müssen sie während der Destrukturierung umbenannt werden, um eine Verschmutzung des lokalen Bereichs zu vermeiden:

// Ausführliche Umbenennung
const { first_name: firstName, last_name: lastName } = response.data;

Dies erhöht den Boilerplate-Code und die Wahrscheinlichkeit von Fehlern.

3. Performance-Mythen: Serialisierung und Netzwerkübertragung

Bezüglich der Performance gibt es zwei verbreitete Mythen: „Feldnamenkonvertierung ist zu langsam“ und „Unterstriche erhöhen die Payload-Größe.“ Lassen Sie uns dies mit Daten klären.

Mythos 1: Laufzeit-Konvertierungs-Overhead

• Dynamische Sprachen: In Python oder Ruby verbraucht die Konvertierung von Feldnamen mittels Regex-Ersetzung bei jeder Anfrage CPU. Moderne Frameworks (wie Pydantic v2, in Rust neu geschrieben) minimieren diesen Overhead jedoch durch vorab berechnete Schema-Mappings.
• Statische Sprachen (Go/Java/Rust): Dies ist effektiv „kostenlos“. Go's Struct-Tags (json:"firstName") oder Java Jacksons Mapping-Caches werden zur Kompilier- oder Startzeit bestimmt. Die Laufzeitausführung beinhaltet einfaches Byte-Kopieren, keine dynamische Berechnung.

Hinweis: Führen Sie niemals eine globale rekursive Konvertierung im Frontend (Browser-Hauptthread) mit Interceptoren (z.B. Axios) durch. Bei großen Antworten führt dies zu Seiten-Jank und Speicherverbrauch. Fazit: Das Backend sollte die Konvertierung übernehmen.

Mythos 2: Übertragungsgröße und Komprimierung

Theoretisch ist first_name ein Byte länger als firstName. Mit aktivierter Gzip- oder Brotli-Komprimierung (Standard-HTTP-Konfiguration) verschwindet dieser Unterschied jedoch praktisch.

• Prinzip: Komprimierungsalgorithmen basieren auf „Duplikats-String-Referenzierung“. In einem JSON-Array sind Schlüssel stark repetitiv. Der Algorithmus speichert first_name beim ersten Auftreten in einem Wörterbuch und ersetzt nachfolgende Vorkommen durch einen winzigen Zeiger.
• Benchmarks: Tests zeigen, dass unter Gzip Level 6 der Größenunterschied zwischen den beiden Stilen typischerweise zwischen 0,5 % und 1 % liegt. Es sei denn, Sie übertragen Daten über Satellitenverbindungen, ist dies kein Problem.

4. Developer Experience (DX) und Kognitive Psychologie

Architektur dreht sich nicht nur um Maschinen; sie dreht sich um Menschen.

• Lesbarkeit von snake_case: Kognitive Psychologie legt nahe, dass Unterstriche eine klare visuelle Trennung bieten. parse_db_xml wird vom Gehirn schneller verarbeitet als parseDbXml, insbesondere bei aufeinanderfolgenden Akronymen (z.B. XMLHTTPRequest vs. XmlHttpRequest). Dies ist ein Grund, warum Stripes Dokumentation als sehr lesbar gilt.
• Konsistenz von camelCase: Der Flow-Zustand, der durch Full-Stack-Konsistenz entsteht, ist kritischer. Für Full-Stack-JS/TS-Teams ermöglicht die Verwendung von camelCase über Frontend und Backend hinweg die direkte Wiederverwendung von Typdefinitionen (Interface/Zod Schema), wodurch die kognitive Last der „mentalen Übersetzung“ vollständig entfällt.

5. Industriestandards und Begründung

6. Tiefgreifender Architektur-Ratschlag: Entkopplung und DTOs

Ein häufiges Anti-Pattern ist „Pass-through“: Datenbankentitäten direkt zu serialisieren, um sie zurückzugeben.

• Wenn Sie dies tun und Ihre DB-Spalten snake_case sind, wird Ihre API snake_case.
• Risiko: Dies verletzt das Prinzip der Informationskapselung, legt Tabellenstrukturen offen und erzeugt eine starke Kopplung zwischen der API und der DB. Wenn die DB umbenannt wird, bricht die API zusammen.

Best Practice: Führen Sie eine DTO (Data Transfer Object)-Schicht ein. Unabhängig davon, wie die zugrunde liegende Datenbank benannt ist, sollten Sie einen unabhängigen API-Vertrag (DTO) definieren. Da Sie ein DTO definieren, warum es nicht als camelCase definieren, um Webstandards einzuhalten? Moderne Mapping-Tools (MapStruct, AutoMapper, Pydantic) handhaben diese Konvertierung mühelos.

7. Blick nach vorne: GraphQL und gRPC

GraphQL: Die Community übernimmt fast 100 % camelCase. Wenn Ihr Team plant, GraphQL in Zukunft einzuführen, ist das Design von REST-APIs mit camelCase jetzt eine kluge Strategie für „Vorwärtskompatibilität“.

gRPC: Der Protobuf-Standard schreibt vor: .proto-Dateien verwenden snake_case für Felddefinitionen, aber sie müssen beim Mapping zu JSON in camelCase konvertiert werden. Dies ist Googles Standardlösung für Mehrsprachigkeit.

8. Zusammenfassung und Entscheidungsmatrix

Es gibt kein absolutes Richtig oder Falsch, nur Kompromisse. Hier ist der endgültige Entscheidungsrahmen:

Empfohlen: Standardmäßig camelCase

Für die überwiegende Mehrheit neuer, allgemeiner RESTful APIs, die Web/App-Clients gegenüberstehen, wird camelCase dringend empfohlen.

Grund: Ausrichtung an der Dominanz von JSON/JavaScript/TypeScript, unter Berücksichtigung der Gewohnheiten von 90 % der Konsumenten.

Tools: Beste Unterstützung durch OpenAPI-Code-Generatoren, Swagger UI und moderne IDEs.

Wann sollte snake_case verwendet werden?

1. Spezifische Konsumenten: Die primären Nutzer der API sind Python-Data Scientists oder System-Ops (Curl/Bash).

2. Altsysteme: Bestehende APIs sind bereits snake_case. Konsistenz > Best Practice. Mischen Sie keine Stile innerhalb desselben Systems.

3. Backend-Geschwindigkeitsextremismus: Verwendung von Python/Ruby ohne Ressourcen zur Pflege einer DTO-Schicht, direkte Weitergabe von Datenbankmodellen.

Entscheidungstabelle

Das Wesen des API-Designs ist Empathie. Im Kontext von Web-APIs ist die Kapselung der Komplexität im Backend (Handling des Mappings) und die Bequemlichkeit für den Benutzer (Anpassung an JS-Gewohnheiten) die Wahl, die größere Professionalität widerspiegelt.