WordPress REST API vs. GraphQL 2026: Der architektonische Showdown

Die Entscheidung hängt heute an technischen Anforderungen, die sich messen lassen: wie viele Requests eine Seite braucht, wie viel JSON der Browser parsen muss, wie Antworten am Edge gecacht werden, woher das Frontend seine Typen bekommt und wer den zusätzlichen Code pflegt. Beide Optionen sind ausgereift. Dieser Leitfaden vergleicht sie in genau diesen Punkten, wobei jeder API-Name, jede Einstellung und jeder Standardwert mit dem REST API Handbook und der WPGraphQL-Dokumentation abgeglichen wurde.

#1. Unterschiede zwischen REST API und GraphQL in WordPress

REST (endpunktbasiert)
  GET /wp-json/wp/v2/posts/101
  GET /wp-json/wp/v2/users/4
  GET /wp-json/wp/v2/categories?post=101
  = mehrere HTTP-Requests, jeder mit fester Antwortstruktur

GraphQL (dokumentbasiert)
  POST /graphql
  query SinglePost {
    post(id: "101", idType: DATABASE_ID) {
      title
      date
      author { node { name } }
      categories { nodes { name slug } }
    }
  }
  = ein HTTP-Request, der Client benennt jedes gewünschte Feld

Die REST API basiert auf festen Ressourcen. Ein Request an /wp-json/wp/v2/posts liefert die vollständige Darstellung des Beitrags: gerenderten Inhalt, Auszug, GUID, Kommentarstatus, Links und mehr. WPGraphQL kehrt das um. Der Client sendet ein Query-Dokument, und der Server liefert nur die Felder, die dieses Dokument nennt.

#Over-fetching und Under-fetching in der REST API

Das WPGraphQL-Team beschreibt das REST-Problem als gleichzeitiges Over-fetching und Under-fetching: Der Posts-Endpunkt liefert Kategorie-IDs, Tag-IDs, Inhalt und Auszug, die eine Listenansicht nicht braucht, und trotzdem fehlen Autorenname und Avatar, wofür weitere Requests nötig sind (WPGraphQL vs WP REST API).

Der Core hat darauf zwei Antworten, die oft übersehen werden. Der globale Parameter _fields gibt nur eine Teilmenge der Felder zurück, zum Beispiel ?_fields=id,title,link, und seit WordPress 5.3 unterstützt er verschachtelte Eigenschaften wie einen einzelnen Meta-Key. Der Parameter _embed bindet verknüpfte Ressourcen (Autor, Beitragsbild, Terms) in dieselbe Antwort ein, und seit WordPress 5.4 lässt er sich auf bestimmte Link-Relationen beschränken (Global parameters). Mit beiden kommt eine REST-Listenansicht nahe an eine GraphQL-Payload heran. Was REST weiterhin fehlt, ist ein typisiertes Schema, gegen das der Client abfragen kann.

#2. Vor- und Nachteile der WordPress REST API

Die WordPress REST API gehört seit einem Jahrzehnt zum Core und ist robuster denn je.

• Die Stärke: Sie funktioniert out of the box. Für die Grundfunktionen sind keine zusätzlichen Plugins nötig. Auf HTTP-Ebene lässt sie sich mit Standard-CDNs sehr gut cachen, weil jede Ressource ihre eigene URL hat.
• Die Schwäche: Over-fetching als Standard. Wenn Sie nur Titel und Slug eines Beitrags brauchen und _fields vergessen, sendet REST das komplette Post-Objekt mit Inhalt und Metadaten. Das verschwendet Bandbreite, besonders mobil.

Die REST API nutzt JSON für Requests und Antworten, und jede Sprache, die HTTP-Requests senden und JSON lesen kann, kann sie verwenden (REST API Handbook). Deshalb sprechen fast alle Integrationsplattformen, CRM-Konnektoren und Webhook-Empfänger zuerst REST.

#3. Vor- und Nachteile von WPGraphQL

GraphQL (meist über WPGraphQL umgesetzt) erlaubt es dem Frontend-Entwickler, die Form der Antwort selbst zu bestimmen.

• Die Stärke: Ein Request, genau die gewünschten Daten. Sie können einen Beitrag, seine Kategorien, die letzten 3 Beiträge des Autors und die Website-Einstellungen in einem einzigen Netzwerk-Round-Trip abrufen. Das Schema ist streng typisiert, und jedes Feld deklariert seinen Typ.
• Die Schwäche: Es erfordert ein zusätzliches Plugin, das gepflegt werden muss. Komplexe Queries können zu langsamen Datenbankabfragen führen, wenn sie nicht durch einen Object Cache (Redis) abgefedert werden.

Die Plugin-Daten, abgelesen im wordpress.org-Plugin-Verzeichnis am 14. Oktober 2026: WPGraphQL 2.24.0, setzt WordPress 6.0 und PHP 7.4 voraus, getestet bis WordPress 7.0.7, mehr als 30.000 aktive Installationen. Laut Plugin-Seite wird WPGraphQL zu einem Canonical Plugin auf WordPress.org. Es folgt Semantic Versioning: Ein Sprung der Hauptversion kündigt Breaking Changes an, und die Release Notes sollten Sie vor dem Update lesen.

#4. Wie WPGraphQL das N+1-Problem löst

Ein naiver Resolver für die letzten 20 Beiträge samt Namen des jeweiligen Autors führt eine Query für die Beiträge aus und danach eine Query pro Autor. Das ist das N+1-Problem. WPGraphQL vermeidet es mit dem DataLoader-Muster: Während der Auflösung sammelt es die benötigten IDs (zum Beispiel alle post_author-Werte) und lädt sie in einem Batch. Im eigenen Beispiel der WPGraphQL-Dokumentation sinken die SQL-Queries für die Autoren von fünf Beiträgen von fünf auf eine (WPGraphQL vs WP REST API).

SELECT * FROM wp_users WHERE ID IN (2, 5, 8, 14);

Zusätzlich hat WPGraphQL einen Model Layer: eine Reihe von PHP-Klassen, die WordPress-Objekte kapseln und sensible Felder wie die E-Mail-Adresse eines Benutzers prüfen, bevor sie zurückgegeben werden (WPGraphQL concepts).

#Wie Sie das WPGraphQL-Schema in PHP erweitern

<?php
declare(strict_types=1);

add_action('graphql_register_types', function (): void {
    register_graphql_object_type('PerformanceMetrics', [
        'description' => __('Measured Core Web Vitals for a post', 'wppoland'),
        'fields' => [
            'lcpSeconds' => ['type' => 'Float'],
            'inpMilliseconds' => ['type' => 'Int'],
            'clsScore' => ['type' => 'Float'],
        ],
    ]);

    register_graphql_field('Post', 'cwvMetrics', [
        'type' => 'PerformanceMetrics',
        'resolve' => function ($post): ?array {
            $raw = get_post_meta($post->databaseId, '_wppoland_cwv_data', true);
            if (!is_array($raw)) {
                return null;
            }
            return [
                'lcpSeconds' => isset($raw['lcp']) ? (float) $raw['lcp'] : null,
                'inpMilliseconds' => isset($raw['inp']) ? (int) $raw['inp'] : null,
                'clsScore' => isset($raw['cls']) ? (float) $raw['cls'] : null,
            ];
        },
    ]);
});

#5. Eigenen REST-Endpunkt in WordPress erstellen

Das Grundmuster ist register_rest_route() am Hook rest_api_init oder eine Klasse, die WP_REST_Controller erweitert. Die Regeln aus dem Handbook, die in Produktion zählen (Adding custom endpoints):

• Seit WordPress 5.5 löst eine Route ohne permission_callback einen _doing_it_wrong-Hinweis aus. Für einen öffentlichen Endpunkt übergeben Sie ausdrücklich __return_true.
• Namespaces sollten dem Muster vendor/v1 folgen, und die Version steigt, wenn Sie die Kompatibilität brechen.
• Fehler sind ein WP_Error, dessen HTTP-Code im Schlüssel status seiner Daten steht, zum Beispiel 400 bei fehlerhafter Eingabe.
• Wenn Sie einen vorhandenen Callback kapseln, geben Sie seinen Rückgabewert durch rest_ensure_response().

<?php
declare(strict_types=1);

class Wppoland_Metrics_Controller extends WP_REST_Controller
{
    protected $namespace = 'wppoland/v1';
    protected $rest_base = 'metrics';

    public function register_routes(): void
    {
        register_rest_route($this->namespace, '/' . $this->rest_base . '/(?P<id>\d+)', [
            [
                'methods' => WP_REST_Server::READABLE,
                'callback' => [$this, 'get_item'],
                'permission_callback' => '__return_true',
                'args' => [
                    'id' => ['type' => 'integer', 'required' => true],
                ],
            ],
            'schema' => [$this, 'get_public_item_schema'],
        ]);
    }

    public function get_item($request)
    {
        $post = get_post((int) $request['id']);
        if (!$post || $post->post_status !== 'publish') {
            return new WP_Error('rest_post_invalid_id', __('Not found.', 'wppoland'), ['status' => 404]);
        }
        return rest_ensure_response([
            'id' => $post->ID,
            'title' => get_the_title($post),
        ]);
    }

    public function get_item_schema(): array
    {
        return [
            '$schema' => 'http://json-schema.org/draft-04/schema#',
            'title' => 'wppoland_metrics',
            'type' => 'object',
            'properties' => [
                'id' => ['type' => 'integer'],
                'title' => ['type' => 'string'],
            ],
        ];
    }
}

add_action('rest_api_init', function (): void {
    (new Wppoland_Metrics_Controller())->register_routes();
});

Die Eigenschaften sind bewusst ohne Typ deklariert: WP_REST_Controller deklariert $namespace und $rest_base untypisiert, und PHP lehnt eine typisierte Neudeklaration in einer Kindklasse ab. Den vollständigen Controller-Durchgang finden Sie in unserem Leitfaden zu eigenen REST-API-Endpunkten.

#6. Ist GraphQL schneller als REST in WordPress

Im Jahr 2026 geht es bei Performance nicht nur um Geschwindigkeit, sondern um Effizienz.

• Netzwerk-Latenz: GraphQL gewinnt bei komplexen Seiten. Weil es mehrere Datenpunkte in einem Request bündelt, entfallen die aufeinanderfolgenden Round-Trips, die eine REST-Seite mit Beitrag, Autor, Terms und verwandten Beiträgen braucht.
• Caching-Strategie: REST gewinnt bei der Einfachheit. Da jeder Endpunkt eine eindeutige URL hat, lässt er sich mit wenig Aufwand global auf Cloudflare cachen. GraphQL braucht GET-Requests oder Persisted Queries für vergleichbare Ergebnisse beim Edge-Caching.
• Server-CPU: Für eine einzelne einfache Ressource ist REST meist leichter. GraphQL muss das Query-Dokument parsen und validieren, bevor es irgendetwas auflöst. Deshalb ist ein Object Cache auf einer GraphQL-Website wichtiger.

Das WPGraphQL-Team hat eine Messung veröffentlicht: Der Abruf von 100 Beiträgen kostete am REST-Endpunkt 335 kb und 7,91 s, bei WPGraphQL 6,4 kb und 67 ms (WPGraphQL vs WP REST API). Das ist ein Test des Herstellers selbst, mit der Standardausgabe von REST. Ein REST-Request mit _fields schließt einen großen Teil der Payload-Lücke, also messen Sie Ihre eigenen Seiten, bevor Sie allein nach diesem Argument entscheiden.

#7. GraphQL mit Persisted Queries im CDN cachen

GraphQL-Queries werden meist als HTTP POST mit der Query im Body gesendet, und ein CDN cacht POST nicht anhand der URL. Laut WPGraphQL selbst ist POST die übliche Methode, GET wird nur eingeschränkt unterstützt (Interacting with WPGraphQL). Das Edge-Caching übernimmt das Begleit-Plugin WPGraphQL Smart Cache (Version 2.3.3, mehr als 6.000 aktive Installationen, inzwischen Teil des WPGraphQL-Monorepos, laut seiner Plugin-Seite).

So funktioniert es laut der Smart-Cache-Dokumentation:

• Network Cache: Um davon zu profitieren, senden Sie für öffentliche Daten HTTP-GET-Requests. Die Antworten tragen einen Header X-GraphQL-Keys mit Tags für alles, was die Query berührt hat. Ändert sich Inhalt, sendet Smart Cache Purge-Events, und der Host entfernt die gecachten Dokumente mit diesen Keys. Der Leitfaden nennt WP Engine und Pantheon als unterstützende Hosts. Das Standard-max-age beträgt 600 Sekunden und lässt sich in den Cache-Einstellungen des Plugins anpassen (Network cache).
• Persisted Queries: Ein Query-Dokument wird auf dem Server in einem nicht öffentlichen Post Type graphql_document gespeichert und über eine Query-ID referenziert. Der Slug des Dokuments ist der SHA-256-Hash der Query, und ein Client kann eine neue queryId nur registrieren, wenn sie zu diesem Hash passt. Clients senden dann kurze GET-Requests wie ?queryId=getPostById&variables={...}. Das Plugin arbeitet mit dem Apollo Persisted Query Link zusammen (Persisted queries).
• Allow- und Deny-Listen: In den Einstellungen für gespeicherte Queries wählen Sie zwischen einem vollständig öffentlichen Endpunkt, dem Zulassen nur bestimmter gespeicherter Queries oder dem Sperren bestimmter Queries. Benutzer mit manage_options sind ausgenommen.

Mit GET-Requests, Persisted Queries und tagbasiertem Purging wird eine GraphQL-Antwort am Edge ähnlich gecacht wie eine REST-URL. Ohne sie fällt das GraphQL-Caching auf den WordPress Object Cache zurück.

#8. WordPress REST Batch API und GraphQL-Batching im Vergleich

WordPress 5.6 hat ein Batch-Framework unter /wp-json/batch/v1 eingeführt. Es nimmt einen POST mit mehreren Teil-Requests an, standardmäßig 25 (Filter rest_get_max_batch_size). GET-Requests werden nicht unterstützt, es ist also für Schreibvorgänge gedacht, und jede Route muss sich bei der Registrierung mit allow_batch dafür freischalten. Der Modus require-all-validate lehnt den gesamten Batch ab, wenn ein einzelner Request die Validierung nicht besteht (REST API batch framework in WordPress 5.6).

#Grenzen des Batchings in der REST API

1. Keine Datenverknüpfung: Teil-Requests laufen als getrennte Operationen. Sie können das Ergebnis von Request A (eine Autor-ID) nicht im selben Batch an Request B übergeben.
2. Auf Schreibvorgänge ausgerichtet: Ohne GET hilft der Batch-Endpunkt einem leselastigen Frontend überhaupt nicht.
3. Am Edge nicht cachebar: Es ist ein POST, also reicht ein CDN jeden Batch an den Origin durch.

GraphQL löst verknüpfte Daten von Haus aus innerhalb einer Query auf, und WPGraphQL akzeptiert zusätzlich gebatchte Queries. Die Sicherheitsdokumentation weist darauf hin, dass Sie Batch-Queries auf der Seite mit den GraphQL-Einstellungen begrenzen oder deaktivieren können.

#9. Paginierungslimits in REST und GraphQL

Die REST API begrenzt per_page auf 100 Datensätze und liefert zu jeder Collection zwei Header: X-WP-Total (Gesamtzahl der Datensätze) und X-WP-TotalPages (Gesamtzahl der Seiten) (Pagination). Ein Client, der 450 Beiträge braucht, sendet fünf Requests.

WPGraphQL nutzt cursorbasierte Connections (first, after, pageInfo { hasNextPage endCursor }). Für die meisten Connections begrenzt es die Einträge pro Connection-Seite auf 100, und der Filter graphql_connection_max_query_amount ändert diese Grenze (WPGraphQL security). Erhöhen Sie sie nur zusammen mit dem Tiefenlimit und Caching, denn größere Seiten machen es billiger, teure Queries zu senden.

#10. Authentifizierung in der WordPress REST API und in WPGraphQL

Die REST API hat zwei eingebaute Methoden (Authentication):

• Cookie-Authentifizierung für Code, der im eingeloggten Dashboard läuft. Ein manueller Request muss eine Nonce für die Aktion wp_rest mitsenden, meist im Header X-WP-Nonce. Ohne Nonce gilt der Request als nicht authentifiziert, auch wenn der Benutzer eingeloggt ist.
• Application Passwords, seit WordPress 5.6 im Core. Sie nutzen Basic Auth und funktionieren nur über HTTPS.

WPGraphQL folgt den WordPress-Berechtigungen: Was WordPress öffentlich zeigt, ist auch in GraphQL öffentlich, und Daten, die in WordPress eine Authentifizierung erfordern, brauchen einen authentifizierten GraphQL-Request. Benutzer ohne veröffentlichte Beiträge sind von öffentlichen Benutzerabfragen ausgeschlossen, und Felder wie die E-Mail-Adresse eines Benutzers erfordern eine bestimmte Berechtigung (WPGraphQL security). Tokenbasierte Login-Abläufe (JWT und Ähnliches) kommen aus Erweiterungen, nicht aus dem Kern-Plugin.

#11. REST API und GraphQL in WordPress absichern

Quellen: WPGraphQL security, REST API Handbook FAQ. Der Weg des Handbooks, anonymen REST-Zugriff zu sperren, ist eine Prüfung mit is_user_logged_in() am Filter rest_authentication_errors. Rate Limiting gehört bei beiden APIs an den Edge (WAF oder CDN), weil weder das Plugin noch der Core eines mitbringen.

#12. TypeScript-Typen aus WPGraphQL generieren

Weil das GraphQL-Schema typisiert und per Introspection lesbar ist, können Werkzeuge wie GraphQL Code Generator das Schema und die Queries des Frontends einlesen und für jedes Query-Ergebnis TypeScript-Typen erzeugen. Ein Feld, das nullable wird oder aus dem Schema verschwindet, lässt dann die Typprüfung im Editor und in der CI scheitern, bevor es in Produktion gelangt.

import type { TypedDocumentNode } from '@graphql-typed-document-node/core';
import { print } from 'graphql';

export async function executeGraphQL<TData, TVariables>(
  document: TypedDocumentNode<TData, TVariables>,
  variables?: TVariables
): Promise<TData> {
  const response = await fetch(import.meta.env.WP_GRAPHQL_ENDPOINT, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ query: print(document), variables }),
  });
  if (!response.ok) throw new Error(`GraphQL HTTP ${response.status}`);
  const { data, errors } = await response.json();
  if (errors?.length) throw new Error(errors[0].message);
  return data;
}

Die REST API veröffentlicht für jede Route ein JSON Schema, sodass sich auch dort Typen erzeugen lassen. Sie stellen sie aber pro Endpunkt zusammen, und der Server validiert nicht, welche Felder Ihr Client auswählt.

#13. Fehlerbehandlung in der REST API und in GraphQL

Ein REST-Fehler ist ein als JSON serialisierter WP_Error mit code, message und data.status, und der HTTP-Status der Antwort entspricht data.status. Schlägt der Request fehl, ist die gesamte Antwort ein Fehler. Für das Monitoring ist das berechenbar, aber eine Seite, die auf einem einzigen REST-Aufruf beruht, kann nicht die Hälfte ihrer Daten rendern.

GraphQL kann Teildaten zurückgeben. Die Antwort enthält sowohl data als auch errors, und jeder Fehler hat einen path, der auf das fehlgeschlagene Feld zeigt:

{
  "data": { "post": { "title": "Headless WordPress architecture", "relatedPosts": null } },
  "errors": [
    { "message": "Internal server error", "path": ["post", "relatedPosts"] }
  ]
}

Das Frontend kann den Artikel rendern und nur für den fehlgeschlagenen Block einen Fallback zeigen. Die Kehrseite: Ein GraphQL-Request, der teilweise fehlgeschlagen ist, liefert trotzdem HTTP 200. Das Monitoring muss also das Array errors auswerten, nicht nur Statuscodes.

#14. GraphQL-Mutations und optimistic UI in WordPress

Schreibvorgänge heißen in GraphQL Mutations. Eine Mutation ändert Daten und liefert das aktualisierte Objekt in derselben Antwort, sodass der Client seinen lokalen Zustand ohne zweiten Request aktualisieren kann. Das Kern-Plugin WPGraphQL bringt Mutations für Beiträge, Terms, Benutzer und Kommentare mit, zum Beispiel createComment:

mutation AddComment($input: CreateCommentInput!) {
  createComment(input: $input) {
    success
    comment { id content date }
  }
}

Das macht Optimistic UI einfach: Die Oberfläche zeigt den neuen Kommentar sofort an und nimmt ihn nur zurück, wenn die Mutation einen Fehler liefert. Mutations für den WooCommerce-Warenkorb gehören nicht zum Kern von WPGraphQL, sie kommen aus einer separaten Erweiterung. Mit REST besteht derselbe Ablauf aus einem POST und dem Auslesen der zurückgegebenen Ressource, was für einzelne Schreibvorgänge genauso gut funktioniert.

#15. GraphQL oder REST für KI-Agenten und die Abilities API

KI-Agenten und MCP-Clients sind inzwischen reguläre API-Nutzer. Mit GraphQL-Introspection kann ein Agent das Schema lesen und sehen, welche Typen und Argumente es gibt. WPGraphQL lässt öffentliche Introspection aber standardmäßig ausgeschaltet, ein Agent braucht also authentifizierten Zugriff oder ein exportiertes Schema.

Der WordPress Core ist einen anderen Weg gegangen. Die Abilities API, seit WordPress 6.9 (2. Dezember 2025) im Core, registriert Operationen mit einem Ein- und Ausgabeschema, einem Permission Callback und einem Execute Callback und stellt sie über die REST-Endpunkte wp-abilities/v1 und den MCP Adapter bereit (Abilities API in WordPress 6.9). Für Agenten, die auf einer Website handeln, ist diese REST-basierte Schicht der native Weg. Mehr dazu in unserem Leitfaden zur WordPress Abilities API.

#16. WordPress APIs mit GraphiQL und Postman testen

• REST: Fast jedem Entwickler vertraut. Endpunkte lassen sich sofort im Browser oder in Werkzeugen wie Postman testen. Hängen Sie ?_envelope an, wenn ein Client keine Header lesen kann: Die Antwort trägt dann Header und Statuscode im Body.
• GraphQL: WPGraphQL bringt GraphiQL mit, eine IDE im Browser innerhalb des WordPress-Backends. Dort durchsuchen Sie das komplette Schema, sehen die verfügbaren Felder und testen Queries und Mutations mit Autovervollständigung. Für Frontend-Teams ist das ein echter Produktivitätsgewinn.

Zur Absicherung gegen Regressionen gleichen Sie die Queries des Frontends bei jedem Merge in der CI mit dem Schema ab, sodass ein entferntes oder umtypisiertes Feld den Build scheitern lässt. Auf der REST-Seite validieren Sie Antworten gegen das JSON Schema der jeweiligen Route.

#17. Von der REST API zu WPGraphQL ohne Ausfallzeit migrieren

1. Parallelbetrieb: Installieren Sie WPGraphQL auf dem Staging mit wp plugin install wp-graphql --activate und bilden Sie jeden Custom Post Type und jede Taxonomie im Schema ab. REST bedient weiter die Produktion.
2. Zuerst reine Leseseiten: Stellen Sie Archiv- und Listenseiten auf GraphQL-Queries mit generierten Typen um und vergleichen Sie Payload und Antwortzeit mit der REST-Version.
3. Detailseiten und Caching: Stellen Sie die Einzelansichten um und ergänzen Sie dann Smart Cache mit GET-Requests oder Persisted Queries, wenn Ihr Host Network Caching unterstützt.
4. REST-Freigaben aufräumen: Behalten Sie die REST-Routen, die Webhooks, Automatisierungen und Integrationen nutzen, und verlangen Sie eine Authentifizierung dort, wo kein öffentlicher Abnehmer mehr übrig ist.

#18. Vergleichstabelle REST API und GraphQL

#Wann GraphQL statt REST API in WordPress

Wenn Sie eine moderne, entkoppelte Website mit React, Astro oder Next.js bauen, passt GraphQL meist besser. Genau das abzufragen, was gebraucht wird, und dazu generierte Typen zu haben, ergibt ein schlankeres und besser wartbares Frontend.

Ignorieren Sie REST jedoch nicht. Für einfache Integrationen, Mobile-Apps, die nur einen Beitrags-Feed brauchen, interne Automatisierungen, Webhooks und KI-Agenten über die Abilities API bleibt die native REST API der schnellste Weg zum Ziel, ohne Plugin, das gepflegt werden muss. Viele produktive Websites nutzen beides: GraphQL für das öffentliche Frontend, REST für Integrationen.

Mehr über die Migration von Websites zu Astro und Next.js bei WPPoland. Den technischen Ablauf beschreibt unser Leitfaden zur Website-Migration auf Next.js und Astro.

Fragen Sie immer noch das komplette Post-Objekt ab, nur für einen Titel? Ergänzen Sie heute _fields und planen Sie den Umstieg auf GraphQL, wenn das Frontend darüber hinauswächst.