CMS und API

API-Schnellstart.

Beginnen Sie mit einer authentifizierten Anfrage, prüfen Sie den Antwortvertrag und ergänzen Sie die Fehlerbehandlung vor der CMS-Anbindung.

Aufgabe und Entscheidung klären

Dieser Leitfaden macht API-Schnellstart zu einem prüfbaren Arbeitsablauf. Er verbindet fachliche Entscheidungen, Zuständigkeiten, Nachweise und Abnahme, damit das Ergebnis dauerhaft im Betrieb funktioniert.

Beginnen Sie mit einer authentifizierten Anfrage, prüfen Sie den Antwortvertrag und ergänzen Sie die Fehlerbehandlung vor der CMS-Anbindung.

Praktischer Ablauf

  1. 1

    Erfassen Sie Quelltypen, Kennungen, Felder, Sprachen, Verantwortliche und Veröffentlichungsstatus.

  2. 2

    Wählen Sie das Auslieferungsmuster nach Volumen, Latenz, redaktioneller Kontrolle und Fehlertoleranz.

  3. 3

    Ordnen Sie den Quelldatensatz einer getrennten Sprachversion mit stabiler Verknüpfung zu.

  4. 4

    Ergänzen Sie Authentifizierung, Idempotenz, Wiederholung, Cache-Invalidierung, Protokollierung und Zugriffssteuerung.

  5. 5

    Testen Sie Veröffentlichung, Quelländerung, fehlende Ergebnisse, Rollback, Tastaturbedienung und Monitoring vor dem Start.

Beispiel oder Werkzeug

Ein vollständiges Anfrage- und Antwortbeispiel umfasst Authentifizierung, Sprache, Modus, Idempotenz und Fehlerbehandlung. Dokumentieren Sie im Werkzeug außerdem Ausgangslage, Verantwortlichkeit, Entscheidung, Nachweis, offenen Punkt und Freigabedatum. Verwenden Sie eine reale Seite oder einen realen Vorgang, damit das Team Abhängigkeiten, Ausnahmefälle und die spätere Pflege erkennt.

PrüfpunktEintragAbnahmekriterium
AusgangslageBeobachteter Ist-ZustandQuelle und Datum vorhanden
EntscheidungGewählte Option mit BegründungRisiko und Zielgruppe berücksichtigt
NachweisTest, Dokument oder MesswertPrüfbar und versionsbezogen
FreigabeName, Rolle und DatumAlle Pflichtkriterien erfüllt

Senden Sie eine produktionsnahe erste Anfrage

Erstellen Sie einen serverseitigen Integrationsclient und speichern Sie die Zugangsdaten in der Geheimnisverwaltung der Laufzeitumgebung. Senden Sie UTF-8-JSON über HTTPS mit stabiler Quellkennung, Quellrevision, Zielsprache, Sprachmodus und Inhalt. Ergänzen Sie einen Idempotenzschlüssel, der bei Wiederholung desselben Auftrags gleich bleibt. Zugangsdaten gehören weder in Browsercode, Repository, CMS-Felder und Bildschirmfotos noch in sichtbare Fehlermeldungen.

Beginnen Sie mit einer repräsentativen, aber nicht schutzbedürftigen Serviceseite. Nehmen Sie Überschriften, Listen, Links und eine rechtliche oder betriebliche Bedingung auf, damit die Antwort den echten Inhaltsvertrag prüft. Lehnen Sie fehlende Quellkennungen, nicht unterstützte Sprachen, unbekannte Modi, zu große Inhalte und fehlerhafte Strukturen vor dem API-Aufruf ab. Setzen Sie feste Verbindungs- und Antwortzeiten und übernehmen Sie eine Korrelationskennung in Ihre Anwendungsprotokolle.

AnfragefeldZweckPrüfung
sourceIdDauerhafte Verbindung zum CMS-DatensatzPflichtfeld, stabil und nicht personenbezogen
sourceRevisionErkennt veraltete ErgebnissePflichtfeld und für die Anfrage unveränderlich
locale und modeWählt die SprachregelnMuss eine aktivierte Kombination sein
idempotencyKeyMacht Wiederholungen sicherDieselbe Operation verwendet denselben Schlüssel

Prüfen Sie den vollständigen Antwortvertrag

Behandeln Sie einen erfolgreichen HTTP-Status nur als erste Prüfung. Validieren Sie Antwortschema, Ergebniskennung, Quellkennung und Revision, Sprache, Sprachmodus, Verarbeitungsstatus, Inhaltsblöcke, Warnungen sowie die angegebene Modell- oder Regelwerksversion. Unbekannte Statuswerte und fehlende Pflichtfelder führen zu einem prüfbaren Integrationsfehler. Bewahren Sie Warnungen am Entwurf auf, weil sie auf Terminologie-, Quellenqualitäts- oder manuelle Prüfanforderungen hinweisen können.

Speichern Sie das Ergebnis als eigene Entwurfsrevision, statt die freigegebene Quelle zu überschreiben. Dokumentieren Sie Anfrage- und Ergebniskennung, Transformationseinstellungen, Zeitpunkte und einen Integritätswert der Quellrevision. Zeigen Sie Prüfenden einen Unterschied an und behandeln Sie jedes Ergebnis passend zum Ausgabeziel. Erzeugtes Markup bleibt bis zur Schema- und Sicherheitsprüfung, Bereinigung, Barrierefreiheitsprüfung und menschlichen Freigabe nicht vertrauenswürdig.

  1. 1

    Validieren Sie die ausgehenden Daten mit einem lokalen Schema.

  2. 2

    Senden Sie die Anfrage mit Authentifizierung, Zeitgrenze, Idempotenz und Korrelationskennung.

  3. 3

    Prüfen Sie Status, Kopfzeilen und Antwortkörper gegen den festgelegten Vertrag.

  4. 4

    Erstellen Sie einen separaten CMS-Entwurf mit Verbindung zur genauen Quellrevision.

  5. 5

    Leiten Sie Warnungen und Unterschiede in die passende redaktionelle Prüfung.

Behandeln Sie Fehler ohne doppelte oder verlorene Arbeit

Wiederholen Sie Zeitüberschreitungen, Verbindungsfehler und Ratenbegrenzungen nur bei idempotenten Vorgängen. Verwenden Sie begrenzte exponentielle Wartezeiten mit Zufallsanteil und beachten Sie eine vom Server genannte Wiederholungszeit. Validierungs-, Authentifizierungs- und Optionsfehler werden erst nach einer Konfigurationsänderung wiederholt. Verschieben Sie ausgeschöpfte Vorgänge in eine Fehlerwarteschlange mit Quellbezug, sicherer Fehlerkategorie, Anzahl der Versuche und nächster Zuständigkeit.

Trennen Sie den sichtbaren Bearbeitungszustand von Diagnosedetails. Die Redaktion braucht klare Zustände wie eingereiht, in Bearbeitung, Entwurf bereit, Handlung erforderlich und fehlgeschlagen mit sicherem nächsten Schritt. Der Betrieb benötigt Anfragekennung, Dauer, Statuskategorie und Wiederholungsverlauf, aber keine vollständigen Quelltexte in Standardprotokollen. Alarmieren Sie bei anhaltender Fehlerquote, steigendem Warteschlangenalter, Authentifizierungsfehlern, Schemaabweichungen und Ergebnissen, deren Quelle während der Bearbeitung geändert wurde.

  • Jede wiederholbare Operation besitzt einen stabilen Idempotenzschlüssel.

  • Wartezeiten sind begrenzt und berücksichtigen Vorgaben zur Ratenbegrenzung.

  • Protokolle enthalten weder Zugangsdaten noch unnötige Inhaltskörper.

  • Fehlereinträge besitzen Verantwortung und ein Verfahren zur erneuten Verarbeitung.

  • Ein veraltetes Ergebnis kann keine neuere Quellrevision unbemerkt ersetzen.

Belegen Sie die Integration vor der Freigabe

Testen Sie gültige Anfragen, jeden dokumentierten Validierungsfehler, abgelaufene und widerrufene Zugangsdaten, Zeitüberschreitungen, Ratenbegrenzung, doppelte Übermittlung, vertauschte Ergebnisreihenfolge, Schemaentwicklung, Inhaltsbereinigung und Quelländerungen während der Bearbeitung. Bestätigen Sie, dass das Monitoring jeden Fehler erkennt und eine geschulte Person den Vorgang ohne Datenbankänderung wiederholen oder schließen kann. Prüfen Sie Barrierefreiheit und Sprache an der gerenderten Darstellung und nicht nur an der Rohantwort.

Veröffentlichen Sie mit eingeschränkten Zugangsdaten, definierten Mengen- und Kostengrenzen, Übersichten, Alarmverantwortung und einem Rückfallschalter, der neue Erzeugung stoppt, ohne veröffentlichte Inhalte zu beeinträchtigen. Legen Sie die unterstützte Vertragsversion fest und terminieren Sie die nächste Aktualisierungsprüfung. Der Abnahmenachweis enthält Testergebnisse, Sicherheitsfreigabe, Datenfluss, redaktionelle Freigabe, Betriebsanleitung und die erfolgreiche Wiederherstellung eines absichtlich fehlgeschlagenen Auftrags.

Rollen, Nachweise und Freigabe

Trennen Sie Erstellung und Veröffentlichung. Eine erfolgreiche Antwort ist ein Entwurf, keine Freigabe. Speichern Sie Quellkennung und Version, Verarbeitungseinstellungen, Ergebniskennung, Prüfstatus, freigebende Person und Veröffentlichungszeit. Wenn sich die Quelle ändert, öffnen Sie die Sprachversion erneut zur Prüfung, statt freigegebene Inhalte still zu ersetzen.

Betrieb und Pflege

Nach der Veröffentlichung endet die Arbeit nicht. Verknüpfen Sie die Sprachversion oder Konfiguration mit ihrer Quelle, überwachen Sie Qualitäts- und Betriebskennzahlen und definieren Sie konkrete Prüfauslöser. Dazu gehören Quelländerungen, Rechtsänderungen, neue Zielgruppenanforderungen, wiederkehrende Supportfragen, technische Änderungen und Vorfälle. Ein klarer Eigentümer bewertet den Auslöser, öffnet bei Bedarf eine neue Revision und dokumentiert die erneute Freigabe.

Checkliste für die Freigabe

  • Die Integration verwendet stabile Quellkennungen.

  • Zugangsdaten liegen serverseitig und werden rotiert.

  • Zeitüberschreitung, Wiederholung und Ratenbegrenzung sind definiert.

  • Wiederholte Anfragen sind idempotent.

  • Erstellte Inhalte gelangen in einen Prüfstatus.

  • Quelländerungen invalidieren oder öffnen die Version erneut.

  • Die Sprachnavigation funktioniert mit Tastatur und assistiven Techniken.

  • Das Monitoring erfasst Fehler, Warteschlangen, Latenz und veraltete Inhalte.

Maßgebliche Quellen

  1. Simple8 API documentation
  2. Simple8 delivery patterns
  3. Web Content Accessibility Guidelines (WCAG) 2.2

Leitfaden praktisch einsetzen

Testen Sie Simple8 mit repräsentativen Inhalten und planen Sie mit der Checkliste einen kontrollierten Produktivprozess.

Eigenen Text testen