Astro-Entwickler in Hannover

Mein Name ist Mariusz Szatkowski. WordPress ist seit 2006 mein Arbeitsfeld, heute baue ich Websites mit Astro. Ich arbeite allein, von Gdynia in Polen aus, vollständig remote und schriftlich. Diese Seite hat ein Thema: die Dateien und Schnittstellen, die eine Astro-Website neben ihren Seiten ausliefert. Das sind RSS und Atom, ein Kalender-Feed, eine kleine JSON-API und die Frage, wie lange all das im Cache bleiben darf. Zahlen und Regeln stammen aus der Astro-Dokumentation und den Spezifikationen. Stand der Pakete am 11.11.2026: astro 7.4.11 und @astrojs/rss 4.0.19 laut npm-Registry.

#Wann eine Firmenwebsite mehr ausliefern sollte als HTML

Die Deutsche Messe führt auf ihrer Übersichtsseite 70 Veranstaltungen, Stand November 2026. Auf den Detailseiten steht als Ort Hannover bei der EuroTier mit EnergyDecentral (10. bis 13. November 2026), bei der PASSION PFERD (3. bis 6. Dezember 2026), bei der Pro Care (2. und 3. Februar 2027) und bei der didacta (23. bis 27. Februar 2027). Wer in Hannover als Zulieferer, Verband, Hotel oder Dienstleister rund um solche Termine arbeitet, schreibt diese Daten heute oft von Hand in eine Tabelle auf der Website.

Dabei können andere Systeme dieselben Daten selbst lesen, wenn die Website sie in einem festen Format anbietet:

• Kunden und Partner abonnieren Ihre Termine im Kalender, statt sie abzutippen.
• Fachjournalisten und Branchenportale abonnieren Ihren RSS-Feed, statt Ihre Seite zu beobachten.
• Ihr Shop, Ihr Intranet oder ein Partnerportal ruft Standort- oder Produktdaten als JSON ab.

Astro hat dafür einen eigenen Mechanismus: Endpunkte. Es ist eine Datei in src/pages/, die keine Seite ausgibt, sondern Daten.

#Statischer Endpunkt oder Server-Endpunkt

Laut Endpunkt-Anleitung legen Sie eine .js- oder .ts-Datei im Ordner pages an. Die Endung wird beim Build entfernt, deshalb gehört die Dateiendung der Ausgabe in den Dateinamen: src/pages/termine.json.ts erzeugt /termine.json. Die Datei exportiert eine Funktion GET, die ein Response-Objekt zurückgibt.

Zwei Stolperstellen aus der Anleitung:

• Endpunkte mit Dateiendung im Namen, etwa sitemap.xml.ts, sind laut Dokumentation nur ohne abschließenden Schrägstrich erreichbar, egal was in build.trailingSlash steht.
• Wer nur GET exportiert, bekommt HEAD kostenlos: Astro ruft GET auf und entfernt den Body. Eine Anfrage mit einer Methode ohne passende Funktion leitet auf die 404-Seite um, außer es gibt eine ALL-Funktion.

#JSON, Dateien und Bilder als Endpunkt

Das einfachste Beispiel aus der Dokumentation ist eine JSON-Datei. Auf Ihre Website übertragen, sieht eine Standortliste so aus:

// src/pages/api/standorte.json.ts
import type { APIRoute } from "astro";
import { standorte } from "../../data/standorte";

export const GET = (() =>
  new Response(JSON.stringify(standorte))) satisfies APIRoute;

satisfies APIRoute gibt Ihnen Typen für params und request, ohne den Typ der Funktion zu verändern. Mit einer Datei [id].json.ts und getStaticPaths() erzeugt Astro pro Eintrag eine eigene Datei, im Beispiel der Dokumentation /api/0.json bis /api/3.json. Für Produktdatenblätter oder Standortseiten ist das der übliche Weg: eine Datei je Datensatz, ausgeliefert wie jede andere statische Datei.

Auch Binärdaten gehen. Die Dokumentation zeigt ein PNG, das der Endpunkt von einer URL holt und als arrayBuffer() ausgibt. Im Server-Modus verlangen laut Dokumentation manche Anbieter den Header Content-Type, damit ein Bild ankommt. Für Hannover ist das nur relevant, wenn Sie Bilder erzeugen lassen wollen, etwa Vorschaukarten für Messetermine. Gehören die Bilder fest zum Inhalt, bleiben sie normale Dateien.

Woher die Daten kommen, ist eine eigene Frage: aus Markdown-Sammlungen, wie auf der Seite für Stuttgart beschrieben, oder aus einem CMS und Produktdaten, wie auf der Seite für Nürnberg. Der Endpunkt liest dieselben Daten wie Ihre Seiten und gibt sie in einem anderen Format aus.

#RSS 2.0 aus einer Content Collection

Für RSS gibt es das Paket @astrojs/rss. Die Anleitung verlangt eine gesetzte site in astro.config, weil daraus die Links entstehen. Der Endpunkt sieht so aus:

// src/pages/rss.xml.js
import rss from "@astrojs/rss";
import { getCollection } from "astro:content";

export async function GET(context) {
  const beitraege = await getCollection("blog");
  return rss({
    title: "Neuigkeiten aus Hannover",
    description: "Termine und Beiträge für Kunden und Partner",
    site: context.site,
    customData: "<language>de-de</language>",
    items: beitraege.map((b) => ({
      title: b.data.title,
      pubDate: b.data.pubDate,
      description: b.data.description,
      link: `/blog/${b.id}/`,
    })),
  });
}

Was dahintersteht, steht in der RSS-2.0-Spezifikation: Ein Kanal braucht title, link und description, und Datumsangaben folgen RFC 822, wobei das Jahr vier Stellen haben darf. Im Helfer ist ein Eintrag gültig, sobald title oder description gesetzt ist. Das README des Pakets beschreibt zusätzlich categories, enclosure mit url, length und type sowie author.

Das README nennt für author die E-Mail-Adresse des Autors. Setzen Sie dort nie die persönliche Adresse eines Mitarbeiters, sondern eine Funktionsadresse oder lassen Sie das Feld weg.

Drei Dinge aus der Anleitung prüfe ich bei jedem Feed:

• Schrägstrich: Der Helfer erzeugt Links mit abschließendem Schrägstrich, egal was in trailingSlash steht. Bei trailingSlash: "never" setze ich trailingSlash: false im Aufruf von rss(), sonst passen Feed und Seiten-URLs nicht zusammen.
• Volltext: Mit dem Feld content kommt der ganze Beitrag als HTML in den Feed. Die Dokumentation empfiehlt, den Text mit einem Paket wie sanitize-html zu bereinigen. Bilder und Links mit relativem Pfad werden nicht unterstützt, sie brauchen volle URLs.
• Autodiscovery: Ein <link rel="alternate" type="application/rss+xml"> im <head> lässt Feed-Reader den Feed von der Startseite aus finden.

#Atom, wenn ein System es verlangt

@astrojs/rss erzeugt RSS, kein Atom. Atom ist in RFC 4287 beschrieben, und ich schreibe es bei Bedarf selbst als Endpunkt mit Content-Type-Header. Die Pflichtfelder sind kurz: Ein Feed braucht id, title und updated, jeder Eintrag ebenfalls. Dazu kommt mindestens ein author, im Feed oder in jedem Eintrag. Die Spezifikation empfiehlt außerdem einen Link mit rel="self" auf die Feed-Adresse.

Mein Vorgehen: RSS als Standard, Atom nur, wenn ein Empfänger ausdrücklich danach fragt. Zwei Formate zu pflegen ohne Bedarf wäre Ballast.

#Ein iCal-Feed für Messetermine

Für Termine ist das Format iCalendar, beschrieben in RFC 5545. Eine Datei src/pages/termine.ics.ts liefert sie aus. Die Regeln der Spezifikation, die ein selbst gebauter Feed einhalten muss:

• Zeilen enden mit CRLF und sollen höchstens 75 Oktette lang sein. Längere Zeilen werden gefaltet, indem man CRLF und ein Leerzeichen einfügt. Gezählt wird in Oktetten, nicht in Zeichen: Ein Umlaut besteht in UTF-8 aus zwei. Die Spezifikation weist darauf hin, dass einfache Implementierungen mitten in einer solchen Folge falten. Mein Code faltet deshalb Zeichen für Zeichen.
• Das Objekt braucht VERSION:2.0 und PRODID.
• Jedes VEVENT braucht UID und DTSTAMP. Die UID muss global eindeutig sein und bleiben, die Spezifikation empfiehlt dafür eine Domain auf der rechten Seite eines @.
• Ganztägige Termine nutzen DTSTART;VALUE=DATE. DTEND ist dann nicht inklusive: Ein Termin vom 3. bis 6. Dezember endet mit DTEND am 7. Dezember.
• In Textwerten werden Komma, Semikolon und Backslash mit einem Backslash maskiert.
• DTSTAMP gibt ohne METHOD an, wann die Information zuletzt geändert wurde, in UTC. Ein Build-Zeitpunkt ist dafür falsch, ich speichere den Stand je Termin.

Die Beispieldaten stammen aus der Messeliste oben. Den Endpunkt unten habe ich lokal mit Node ausgeführt: Die Ausgabe hat CRLF-Zeilenenden, keine Zeile länger als 75 Oktette, das Komma im Titel ist maskiert und DTEND liegt einen Tag nach dem Ende.

// src/pages/termine.ics.ts
import type { APIRoute } from "astro";

const termine = [
  { id: "passion-pferd-2026", titel: "PASSION PFERD", start: "2026-12-03", ende: "2026-12-06", stand: "2026-11-11T09:00:00Z" },
  { id: "didacta-2027", titel: "didacta", start: "2027-02-23", ende: "2027-02-27", stand: "2026-11-11T09:00:00Z" },
];

const tag = (d: string) => d.replaceAll("-", "");
const folgetag = (d: string) => {
  const x = new Date(`${d}T00:00:00Z`);
  x.setUTCDate(x.getUTCDate() + 1);
  return tag(x.toISOString().slice(0, 10));
};
const text = (s: string) => s.replace(/[\;,]/g, (m) => `\\${m}`);
const utc = (iso: string) => iso.replace(/[-:]/g, "");

function falten(zeile: string) {
  const enc = new TextEncoder();
  const zeilen: string[] = [];
  let teil = "";
  let bytes = 0;
  for (const zeichen of zeile) {
    const n = enc.encode(zeichen).length;
    if (bytes + n > (zeilen.length ? 74 : 75)) {
      zeilen.push(teil);
      teil = "";
      bytes = 0;
    }
    teil += zeichen;
    bytes += n;
  }
  zeilen.push(teil);
  return zeilen.join("\r\n ");
}

export const GET = (() => {
  const zeilen = ["BEGIN:VCALENDAR", "VERSION:2.0", "PRODID:-//Beispiel GmbH//Termine//DE"];
  for (const t of termine) {
    zeilen.push(
      "BEGIN:VEVENT",
      `UID:${t.id}@example.com`,
      `DTSTAMP:${utc(t.stand)}`,
      `DTSTART;VALUE=DATE:${tag(t.start)}`,
      `DTEND;VALUE=DATE:${folgetag(t.ende)}`,
      `SUMMARY:${text(`${t.titel}, Messe in Hannover`)}`,
      "END:VEVENT",
    );
  }
  zeilen.push("END:VCALENDAR");
  return new Response(zeilen.map(falten).join("\r\n") + "\r\n", {
    headers: { "Content-Type": "text/calendar; charset=utf-8" },
  });
}) satisfies APIRoute;

Eine Bibliothek ist für diesen Umfang nicht nötig. Wächst der Feed um Wiederholungen oder Zeitzonen, wechsle ich auf ein geprüftes Paket, statt die Regeln der Spezifikation nachzubauen.

#Eine kleine JSON-API für andere Systeme

Sobald ein anderes System nicht nur liest, sondern Daten schickt oder gefilterte Antworten braucht, ist der Server-Endpunkt richtig. Die Dokumentation zeigt das Muster, das ich dafür nutze:

// src/pages/api/termine/[id].json.ts
import type { APIRoute } from "astro";
import { findeTermin } from "../../../data/termine";

export const prerender = false;

export const GET = (async ({ params }) => {
  const termin = await findeTermin(params.id);
  if (!termin) {
    return new Response(null, { status: 404, statusText: "Not found" });
  }
  return new Response(JSON.stringify(termin), {
    status: 200,
    headers: { "Content-Type": "application/json" },
  });
}) satisfies APIRoute;

Wichtig sind der Statuscode und der Header, die ein statischer Endpunkt nicht setzen kann. Für POST prüft die Dokumentation den Header Content-Type und antwortet sonst mit 400. Das übernehme ich, und ich ergänze eine Prüfung der Felder, bevor irgendetwas weiterverarbeitet wird.

Ein Server-Endpunkt braucht einen Adapter und ein Hosting, das Code ausführt. Das ändert den Betrieb deutlich: Es gibt etwas, das ausfallen, langsam werden oder angegriffen werden kann. Deshalb frage ich zuerst, ob die Antwort wirklich pro Anfrage berechnet werden muss. Bei Terminlisten und Standortdaten lautet die Antwort meist nein, dann bleibt es bei der Datei. Wie Sie solche Antworten mit Sicherheits-Headern absichern, steht auf der Seite für Frankfurt.

#Datenschutz in Niedersachsen: auch ein Datenangebot ist ein digitaler Dienst

Foto: Ralf Roletschek, CC BY-SA 3.0, Wikimedia Commons.

Zuständig für Datenschutz bei Unternehmen in Niedersachsen ist der Landesbeauftragte für den Datenschutz Niedersachsen. Auf seiner Seite für Betreiber von Webseiten und Apps steht, dass grundsätzlich jede Webseite und jede App ein digitaler Dienst ist. Als Beispiele nennt er das Angebot von Verkehrs-, Wetter-, Umwelt- oder Börsendaten. Für solche Dienste gelten neben der DSGVO die §§ 19 bis 26 des TDDDG, das seit dem 13. Mai 2024 in Kraft ist.

Für Endpunkte heißt das in der Praxis:

• Eine Schnittstelle gehört zum Angebot, nicht in einen rechtsfreien Raum neben der Website. Was für die Seite gilt, gilt auch für sie.
• In Feeds und API-Antworten stehen keine personenbezogenen Daten, die nicht ausdrücklich dorthin gehören: keine persönliche E-Mail im RSS-Feld author, keine Namen von Teilnehmern im Kalender.
• Ein Server-Endpunkt, der Anfragen verarbeitet, schreibt in der Regel Protokolle. Was dort steht und wie lange, klären Sie mit Ihrem Hoster und tragen es in Ihre Datenschutzerklärung ein.

Rechtsberatung ist das nicht. Ich setze technisch um, was Ihr Datenschutzbeauftragter oder Ihre Kanzlei festlegt.

#Caching: drei Ebenen, drei Regeln

Bei einer statischen Datei sieht die Konfiguration je Hoster anders aus. Auf Cloudflare Pages liegt dafür eine Datei _headers im Ordner public/. Die Dokumentation sagt ausdrücklich, dass diese Header nicht auf Antworten von Pages Functions angewendet werden. Wer einen Server-Endpunkt betreibt, setzt sie deshalb im Code.

Bei einem Server-Endpunkt setze ich Cache-Control an der Response, wie die Astro-Dokumentation es für Seiten mit Astro.response.headers zeigt. Die MDN-Seite erklärt die Bausteine:

• s-maxage gilt nur für gemeinsame Caches und überschreibt dort max-age.
• stale-while-revalidate erlaubt einem Cache, nach Ablauf der Frische noch eine begrenzte Zeit die alte Antwort auszuliefern und im Hintergrund neu zu prüfen. Die Erweiterung steht in RFC 5861.
• private erlaubt nur den Cache im Browser. MDN empfiehlt es für personalisierte Inhalte, weil eine vergessene Angabe die Antwort in einem gemeinsamen Cache für andere Nutzer verfügbar macht.

Ein Feed oder Kalender, der sich einmal am Tag ändert, braucht keinen Server. Er braucht einen Build, der bei jeder Änderung läuft, und eine Aktualität, die Ihr Team bewusst festlegt.

#Checkliste: Welcher Endpunkt für welchen Zweck

#Wie ein Projekt mit mir abläuft

Sie schicken mir schriftlich, welche Daten welche Systeme lesen sollen. Ich antworte mit Rückfragen und einer schriftlichen Beschreibung von Umfang und Annahmen. Gebaut wird auf einer Staging-Adresse, die Sie prüfen, bevor etwas live geht. Danach folgt die Abnahme, und auf Wunsch eine laufende Wartung, in der Updates erst auf Staging getestet werden. Gestaltung, Layouts und Wireframes kommen von Ihnen, ich setze sie technisch um. Ich arbeite remote, ohne Termine vor Ort und ohne Telefonate, alles läuft über Ihre Rückmeldungen im Text.

Vor dem Start brauche ich: Zugang zu Repository und Hosting, Lesezugriff auf die Datenquelle und eine Liste der Empfänger, die den Feed oder die API später nutzen sollen.

#Fragen und Antworten

#Brauche ich für einen RSS-Feed oder einen Kalender-Feed einen Server?

Nein. Laut Astro-Dokumentation werden Endpunkte in einem statischen Projekt beim Build aufgerufen und erzeugen Dateien. Ein Feed ist dann eine Datei wie jede andere und wird erst bei einem neuen Build aktualisiert. Einen Server brauchen Sie nur, wenn die Antwort pro Anfrage anders aussehen muss.

#RSS oder Atom, was soll ich anbieten?

Für eine Firmenwebsite reicht meist RSS 2.0, weil der Astro-Helfer @astrojs/rss es fertig erzeugt. Atom (RFC 4287) schreibe ich bei Bedarf als eigenen Endpunkt. Es hat feste Pflichtfelder, darunter eine eindeutige id und ein Aktualisierungsdatum pro Eintrag und für den Feed.

#Warum steht im Kalender-Feed kein Zeitstempel vom Build?

Weil DTSTAMP laut RFC 5545 ohne METHOD angibt, wann die Information zuletzt geändert wurde. Ein Build-Zeitpunkt würde jeden Termin bei jedem Build als geändert ausweisen. Ich speichere den Stand deshalb je Termin.

#Wann lohnt sich der Servermodus für eine Schnittstelle?

Wenn die Antwort von der Anfrage abhängt: Abfrage von Parametern, Prüfung eines Tokens, Daten, die sich im Minutentakt ändern, oder ein POST von einem anderen System. Für Terminlisten, Produktlisten oder Standortdaten, die sich selten ändern, ist die statische Datei einfacher zu betreiben.

#Darf in einem Feed oder einer API ein Ansprechpartner mit E-Mail stehen?

Technisch ja, datenschutzrechtlich nur mit Grund. Das Feld author im RSS-Helfer erwartet laut Dokumentation eine E-Mail-Adresse. Persönliche Adressen gehören nicht in einen öffentlichen Feed, eine Funktionsadresse reicht fast immer.

#Was brauche ich von Ihnen, bevor es losgeht?

Die Adresse der Website, die Systeme, die Ihre Daten lesen sollen, die Quelle der Daten und einen Termin, falls es einen gibt. Das Layout kommt von Ihnen, die technische Umsetzung liegt bei mir.

#Ihre Anfrage an mich

Über das Kontaktformular erreichen Sie mich. Nennen Sie die Adresse der Website, welche Daten als Feed, Kalender oder Schnittstelle nach außen gehen sollen, wer sie lesen soll, Ihren Termin und den Stand: Astro-Version, Hosting, Datenquelle. Ich antworte schriftlich, erst mit Rückfragen, dann mit einer Einschätzung des Aufwands. Die erste Einschätzung ist kostenlos und unverbindlich. Alle Astro-Leistungen im Überblick stehen auf der Seite Astro-Entwickler, mehrsprachige Websites auf der Seite für Zürich.