--- term: 'API-Endpoint' seoTitle: 'Was ist ein API-Endpoint? Aufbau, Beispiele, Best Practices' headline: 'Was ist ein API-Endpoint?' slug: api-endpoint category: api-realtime shortDefinition: 'Ein API-Endpoint ist eine bestimmte URL, unter der eine API Anfragen für eine Ressource annimmt – mit einer HTTP-Methode definiert er eine Operation.' relatedTerms: - api - rest-api - api-gateway-architecture - auto-generated-database-apis contrastsWith: - api-gateway-architecture aboutTerms: - 'Base URL' - 'Path Parameters' - 'Query Parameters' faq: - question: 'Was ist ein API-Endpoint, einfach erklärt?' answer: 'Die bestimmte URL, unter der eine API Anfragen zu einer Ressource entgegennimmt – jeder Endpoint ist eine Tür in die API. Eine Anfrage an /users/42 mit der Methode GET verlangt die Daten von Benutzer 42; derselbe Pfad mit DELETE verlangt seine Löschung. Die API ist das ganze Gebäude, die Endpoints sind ihre adressierbaren Türen.' - question: 'Was ist ein Beispiel für einen API-Endpoint?' answer: 'https://api.example.com/v1/users/42 – eine Basis-URL (Schema, Host und Version), dann ein Pfad, der die Ressource benennt. Entsprechungen aus der Praxis: der Endpoint /repos/OWNER/REPO einer Code-Hosting-Plattform oder der automatisch generierte Endpoint /classes/Todo einer Back4app-Anwendung für eine Datenklasse Todo.' - question: 'Was ist der Unterschied zwischen einer API und einem Endpoint?' answer: 'Die API ist der gesamte Vertrag – die vollständige Menge an Regeln, Ressourcen und Operationen, die ein Dienst bereitstellt. Ein Endpoint ist ein einzelner Zugangspunkt darin. Eine API stellt viele Endpoints bereit, und eine API-Dokumentation ist über weite Strecken deren Katalog.' - question: 'Ist ein Endpoint dasselbe wie eine URL?' answer: 'Nicht ganz. Der Endpoint wird als URL ausgedrückt, aber die URL ist nur die Adresse; der Endpoint ist der Interaktionspunkt, den sie bezeichnet. Dokumentationen schreiben Endpoints üblicherweise als Pfade, die Basis-URL stillschweigend vorausgesetzt – und genau genommen gehört die HTTP-Methode zu dem, was die Operation an dieser Adresse definiert.' - question: 'Kann dieselbe URL mehr als ein Endpoint sein?' answer: 'Ja. GET /users/42 und DELETE /users/42 teilen sich eine URL, sind aber verschiedene Operationen – deshalb modelliert der Standard OpenAPI eine API als Pfade, von denen jeder mehrere nach Methode geschlüsselte Operationen hält. Wenn Leute "Endpoints" zählen, zählen sie in Wirklichkeit Operationen.' - question: 'Was ist der Unterschied zwischen einem Endpoint und einer Route?' answer: 'Eine Frage der Perspektive. Eine Route ist die serverseitige Definition – ein Pfadmuster, eine Methode und eine Handler-Funktion in Ihrem Framework. Der Endpoint ist die zum Client zeigende URL, unter der diese Route erreichbar ist. Dieselbe Sache, von den entgegengesetzten Enden der Anfrage betrachtet.' - question: 'Wie finde ich die Endpoints einer API?' answer: 'Drei Wege, nach Verlässlichkeit geordnet: die Dokumentation oder die maschinenlesbare OpenAPI-Spezifikation lesen, die jeden Pfad und jede Operation aufzählt; den echten Verkehr im Netzwerk-Tab der Entwicklerwerkzeuge des Browsers beobachten, gefiltert auf fetch/XHR; oder Aufrufe mit curl und einem API-Client durchspielen, um das Verhalten zu bestätigen.' - question: 'Wie sichert man einen API-Endpoint ab?' answer: 'Behandeln Sie jeden Endpoint als Angriffsfläche: ausschließlich HTTPS, Authentifizierung auf jeder Route, Autorisierung nach dem Prinzip der geringsten Rechte, Eingabevalidierung, Rate Limits, begrenzte Paginierung und Fehlermeldungen, die nichts über das Innenleben verraten. Führen Sie danach eine Inventur – vergessene "Zombie"-Endpoints gehören zu den häufigsten API-Sicherheitslücken.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'RFC 3986 — URI: Generic Syntax' url: 'https://datatracker.ietf.org/doc/html/rfc3986' - name: 'RFC 9110 — HTTP Semantics' url: 'https://www.rfc-editor.org/rfc/rfc9110' - name: 'OpenAPI Specification — Paths and Operations' url: 'https://spec.openapis.org/oas/latest.html#paths-object' - name: 'OWASP API Security Top 10' url: 'https://owasp.org/API-Security/' cta: title: 'Endpoints, die Sie nie entwerfen mussten' text: 'Legen Sie auf Back4app eine Klasse an, und ihre REST-Endpoints existieren sofort – Ressourcen-URLs, Methoden, Authentifizierung und Berechtigungen übernimmt die Plattform, einheitlich über Ihr gesamtes Datenmodell.' linkText: 'Kostenlos starten' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-23' translationKey: api-endpoint --- **Ein API-Endpoint ist eine bestimmte URL, unter der eine API Anfragen für eine Ressource annimmt – mit einer HTTP-Methode definiert er eine Operation.** Diesen zweiten Halbsatz lassen die meisten Definitionen weg, und genau er löst die klassische Verwechslung auf: `GET /users/42` und `DELETE /users/42` teilen sich eine Adresse, sind aber verschiedene Endpoints – so wie sich eine Tür anders verhält, je nachdem, ob Sie anklopfen oder den Schlüssel drehen. ## Das Wichtigste in Kürze | Frage | Antwort | | --- | --- | | Die Formel | Basis-URL + Pfad (+ Methode) = eine Operation auf einer Ressource | | vs. die API | API = der ganze Vertrag · Endpoint = ein Zugangspunkt darin | | Pfad vs. Query | Der Pfad sagt, *welche* Ressource · die Query, *wie* sie zurückkommt | | Benennung | Substantive im Plural, klein, flache Verschachtelung – das Verb trägt die Methode | | Sicherheit | Jeder Endpoint ist Angriffsfläche – auch die vergessenen | ## Aufbau der URL eines API-Endpoints Jedes Stück einer echten Anfrage-URL, beschriftet – nach der Grammatik von [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986): ```text GET https://api.example.com/v1/users/42/posts?status=published&limit=20 GET Methode — die Aktion; Teil der Identität der Operation https Schema — TLS, nicht verhandelbar api.example.com Host ┐ die Basis-URL, geteilt von /v1 Version ┘ jedem Endpoint der API /users/42/posts Pfad — die Ressource: Posts von Benutzer 42 42 Pfad-Parameter — identifiziert WELCHE Ressource ?status=published Query-Parameter — WIE sie zurückgegeben wird: &limit=20 filtern, sortieren, paginieren (nicht Teil der Identität) ``` Einen Endpoint aus dem Anwendungscode aufrufen – das SDK setzt URL, Methode und Authentifizierung für Sie zusammen: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // Every class gets endpoints automatically — this call hits one const query = new Parse.Query('Todo'); query.equalTo('done', false); query.limit(10); const todos = await query.find(); // Endpoint used: GET /classes/Todo?where={"done":false}&limit=10 ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // Every class gets endpoints automatically — this call hits one final query = QueryBuilder(ParseObject('Todo')) ..whereEqualTo('done', false) ..setLimit(10); final response = await query.query(); // Endpoint used: GET /classes/Todo?where={"done":false}&limit=10 ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // Every class gets endpoints automatically — this call hits one let query = Todo.query("done" == false) .limit(10) let todos = try await query.find() // Endpoint used: GET /classes/Todo?where={"done":false}&limit=10 ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // Every class gets endpoints automatically — this call hits one val query = ParseQuery.getQuery("Todo") query.whereEqualTo("done", false) query.limit = 10 val todos = query.find() // Endpoint used: GET /classes/Todo?where={"done":false}&limit=10 ``` ## Endpoint vs. API vs. URL vs. Route Die Abgrenzung zwischen vier Begriffen, die keine einzelne Ranking-Seite anbietet: | Begriff | Was es ist | Wessen Vokabular | | --- | --- | --- | | API | Der ganze Vertrag: alle Ressourcen, Operationen und Regeln | Das aller Beteiligten | | Endpoint | Ein Zugangspunkt – eine URL (+ Methode), die Anfragen für eine Ressource annimmt | Die Sicht des Konsumenten | | URL | Die Adresszeichenkette, die den Endpoint auffindbar macht ([RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986)) | Die Sicht der Leitung | | Route | Die serverseitige Definition: Pfadmuster + Methode + Handler-Code | Die Sicht der Umsetzung | Endpoint und Route sind dieselbe Sache von entgegengesetzten Enden gesehen: Ein Framework deklariert eine Route, ein Client ruft einen Endpoint auf. Und die [OpenAPI Specification](https://spec.openapis.org/oas/latest.html#paths-object) formalisiert das ganze Bild – eine API ist eine Menge von *Pfaden*, jeder Pfad hält nach Methode geschlüsselte *Operationen*, und "wie viele Endpoints hat diese API?" ist in Wahrheit eine Zählung von Operationen. ```mermaid flowchart LR accTitle: Wie eine Anfrage über einen Endpoint zu einer Ressource gelangt accDescr: Eine Client-Anfrage mit Methode und URL trifft auf die Basis-URL der API, wird über Pfad und Methode der Route eines Endpoints zugeordnet, durchläuft Authentifizierung und Validierung, und der Handler arbeitet auf der zugrunde liegenden Ressource, bevor eine Antwort zurückgeht. C["Client
GET /v1/users/42/posts"] --> B["Basis-URL der API
Routenzuordnung: Pfad + Methode"] B --> A["Auth · Validierung
Rate Limits"] A --> H["Handler
(der Code der Route)"] H --> R[("Ressource:
Posts von Benutzer 42")] R --> H --> C ``` ## Pfad-Parameter vs. Query-Parameter Die Regel, die die meisten Designdebatten beendet – **Identität in den Pfad, Modifikation in die Query**: | Frage, die der Parameter beantwortet | Gehört in | Beispiel | | --- | --- | --- | | *Welche* Ressource? | Pfad | `/users/42`, `/orders/2026-1187` | | Welche *verbundene* Collection? | Pfad | `/users/42/posts` | | Ergebnisse filtern? | Query | `?status=published` | | Sortieren oder paginieren? | Query | `?sort=-createdAt&limit=20` | | Optionale Verhaltensanpassungen? | Query | `?include=author&fields=title` | Die Unterscheidung hat Folgen: Pfad-Parameter gehören zur Identität der Ressource (und zum Cache-Schlüssel), Query-Parameter formen die Repräsentation. Eine Ressource, die nur über Query-Parameter erreichbar ist (`/getData?type=user&id=42`), ist der klassische Geruch nach Stufe 0, bei dem die Reifegradleiter von [REST](/glossary/de/rest-api/) beginnt. ## Endpoints gut benennen Konsumenten bewerten eine API anhand ihrer Endpoint-Liste, bevor sie ein Wort der Dokumentation gelesen haben: | Konvention | Gut | Schlecht | | --- | --- | --- | | Substantive, keine Verben – das Verb ist die Methode | `POST /orders` | `POST /createOrder` | | Collections im Plural | `/users`, `/users/42` | `/user/42` | | Kleinschreibung, mit Bindestrich | `/purchase-orders` | `/PurchaseOrders`, `/purchase_orders` | | Flache Verschachtelung (eine Ebene) | `/users/42/posts` | `/users/42/posts/8/comments/3/likes` | | Versionspräfix mit Richtlinie | `/v1/…` + Deprecation-Fristen | `/v1` stillschweigend brechen | | Vorhersagbare Muster | Dieselbe Form für jede Ressource | Jede Ressource in eigenem Dialekt | ## Endpoints absichern: die Checkliste Jeder Endpoint ist eine Tür, und Angreifer probieren alle – auch die, die Sie vergessen haben. Die kompakte Checkliste: **ausschließlich HTTPS**; **Authentifizierung auf jedem Endpoint** (keine aus dem Internet erreichbaren "internen" Ausnahmen); **Autorisierung pro Ressource**, nicht nur pro API – Benutzer 42, der `/users/43/orders` liest, ist das klassische Loch Broken Object Level Authorization; **Eingabevalidierung** für Pfad, Query und Body; **[Rate Limits](/glossary/de/api-rate-limiting/)**, bemessen an den Kosten des Endpoints; **begrenzte Paginierung**, damit kein Endpoint unbegrenzte Collections zurückgibt; **Fehlerhygiene** (keine Stack Traces, keine Existenzverräter). Und der Punkt, den Teams übersehen: die **Inventur**. Undokumentierte, abgekündigte, aber noch lebende "Zombie"-Endpoints haben einen eigenen Eintrag in den [OWASP API Security Top 10](https://owasp.org/API-Security/) – einen Endpoint, an den Sie sich nicht erinnern, verteidigen Sie auch nicht. ## Typische Anwendungsfälle Wo das Denken in Endpoints sich auszahlt: - **Eine fremde API konsumieren** – der Endpoint-Katalog der Dokumentation *ist* das Produkt; wer den Aufbau kennt, kann ihn lesen. - **Eine öffentliche API entwerfen** – Entscheidungen zu Benennung, Parameterplatzierung und Versionierung, mit denen Konsumenten jahrelang leben. - **Integrationen debuggen** – einen SDK-Aufruf als rohe Endpoint-Anfrage mit curl nachzustellen trennt Client- von Serverfehlern. - **Gateway und Monitoring konfigurieren** – [Rate Limits](/glossary/de/api-gateway/), Alarme und Zugriffsregeln werden pro Endpoint deklariert. - **Sicherheitsaudits** – das Endpoint-Inventar ist die Karte der Angriffsfläche; das Audit beginnt mit seiner Aufzählung. ## Sollte es ein neuer Endpoint sein? Eine Entscheidungsmatrix | Situation | Antwort | | --- | --- | | Neue Art von Ressource | Neuer Endpoint (`/invoices`) | | Gleiche Ressource, engere Ergebnisse | Bestehender Endpoint + Query-Parameter | | Gleiche URL, andere Aktion | Gleicher Pfad, andere Methode | | Ein Screen braucht fünf Endpoints | Composite-Endpoint erwägen – aber siehe Wildwuchs unten | | Abweichende Repräsentation (Felder, Format) | Query-Parameter oder Content Negotiation, kein neuer Pfad | | Brechende Änderung an Form oder Semantik | Neues Versionspräfix, mit einer Deprecation-Frist | ## Grenzen und Trade-offs - **Endpoint-Wildwuchs ist echte Schuld.** Endpoints pro Screen und pro Team sammeln sich an; jeder ist für immer Dokumentation, Tests, Monitoring und Angriffsfläche. Wenige, gut entworfene Endpoints schlagen viele maßgeschneiderte. - **Feste Formen passen nicht zu jedem Konsumenten.** Ein Endpoint gibt zurück, was er zurückgibt – der Trade-off aus [Overfetching und Underfetching](/glossary/overfetching-underfetching/), für den es abfragegeformte APIs gibt. - **URLs sind Verträge.** Einen Endpoint umzubenennen bricht jeden Konsumenten; wählen Sie Namen, mit denen Sie leben können, denn Migration bedeutet Versionierung, Weiterleitungen und Abkündigungskalender. - **Die Methode ist in der Umgangssprache unsichtbar.** "Der /users-Endpoint" verschweigt, ob Lesen oder Schreiben gemeint ist – in Dokumentation, Logs und Sicherheitsregeln zählt Präzision. - **Endpoints zu zählen misst nichts.** Eine API mit 12 stimmigen Endpoints schlägt regelmäßig eine mit 400 improvisierten; das Qualitätssignal ist Governance, nicht Menge. ## API-Endpoints mit Back4app Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Endpoints sind hier *abgeleitet, nicht entworfen*: Eine Klasse `Todo` anzulegen stellt sofort `/classes/Todo` und `/classes/Todo/:objectId` mit dem vollständigen Methodensatz bereit – das Muster der [automatisch generierten API](/glossary/de/automatisch-generierte-apis/) – dazu feste Endpoints für Benutzer, Sessions, Dateien und Funktionen, alle mit einer gemeinsamen Basis-URL, schlüsselbasierter Authentifizierung und Berechtigungen pro Klasse. Die Code-Tabs zeigen die praktische Folge: Das SDK setzt Endpoint, Methode und Zugangsdaten für Sie zusammen, und die Checkliste oben – einheitliche Benennung, Authentifizierung überall, begrenzte Abfragen, keine Zombies – kommt als Plattformverhalten statt als Disziplin im Review. Eigene Operationen bekommen Endpoints auf demselben Weg: Deployen Sie eine Cloud-Code-Funktion, und `/functions/ihreFunktion` existiert.