Zusammenfassung

  • Copy API Query übernimmt die Filter aus der PeeringDB Advanced Search in eine Abfrage für curl oder gängige Skriptsprachen und senkt den Aufwand zwischen Websuche und Automatisierung.
  • Die optionale Stadtkarte und die Ergebnistabelle helfen, Facility-Einträge zu finden. Sie belegen weder einen aktiven Port noch eine ausgewählte Route, verfügbare Leistung oder einen Vertrag.

Analyse

Eine Suchliste kann zum Standortentscheid werden

Ein Infrastrukturteam muss entscheiden, welche Betreiber es anspricht, welche Facilities es prüft und welche Angebote den nächsten Planungsschritt rechtfertigen. Hinter dieser Vorauswahl stehen technische Prüfzeit und Beschaffungsarbeit; sie kann auch die Standortplanung für Netze prägen, von denen Kundinnen und Kunden später verlässliche Konnektivität erwarten. Das ist eine allgemeine Entscheidungslage, keine von PeeringDB berichtete Fallstudie. Wird eine Kandidatenliste zu früh als Freigabe behandelt, können Standortreservierung, Cross-Connect-Bestellung und Terminplanung folgen, bevor die Verbindung bestätigt ist.

Die Karte hilft bei der Frage, wo ein Eintrag liegt; sie sagt nicht, ob ein Betreiber die nötige Kapazität oder die passende Anbindung tatsächlich bereitstellt.

In seinem Produktupdate vom September 2026 meldete PeeringDB, dass Copy API Query für Advanced Search ausgeliefert wurde. Nach einer Websuche lässt sich die Abfrage mit curl oder in einem Format für gängige Skriptsprachen weiterverwenden. Damit werden die Filter eines Planungsteams leichter überprüfbar und übergebbar. Die Datenbank wird dadurch nicht verbindlicher; der Übergang vom Browser in einen wiederholbaren Arbeitsablauf wird lediglich kürzer.

Der wirtschaftliche Effekt ist klein, aber greifbar: Von der Erkundung bis zu einer wiederholbaren Auswahlliste fällt ein manueller Schritt weg. Ein Netzwerktechniker kann die geografische Auswahl erst in der Weboberfläche prüfen, bevor ein Skript die Ergebnisse verarbeitet. Ein Analyst kann Kollegen die Suchbedingungen mitgeben statt eines Bildes, dessen Filter sich kaum rekonstruieren lassen. PeeringDBs Suchanleitung beschreibt erweiterte Filter für Ort, Netzpräsenz, Serviceniveau und weitere Merkmale sowie Exporte in JSON und CSV. Einige Funktionen, darunter die Radius-Suche, setzen eine Anmeldung voraus.

Die kopierte Abfrage macht die Übergabe nachvollziehbarer, ersetzt aber nicht das Verständnis der Parameter und Zugriffsbedingungen.

Die Karte zeigt Einrichtungen, nicht Verbindungen

Das Update beschreibt außerdem eine optionale Karte auf den jeweils passenden Advanced-Search-Seiten. Ein Schalter im Profil aktiviert sie. Sie zeigt die Verteilung von Facilities innerhalb einer Stadt neben der Ergebnistabelle. Für eine GIS-Auswertung mit mehreren ein- und ausblendbaren Datenschichten gibt es weiterhin einen separaten KMZ-Download aller Facilities.

Die Stadtkarte beantwortet eine Frage, die eine Namensliste offenlässt: Liegen die Kandidaten dicht beieinander oder über verschiedene Teile der Stadt verteilt? Die Darstellung macht räumliche Cluster und Distanzen sichtbar; die Tabelle hält die zugehörigen Einträge fest. Das verbessert die geografische Suche.

Sie zeigt jedoch weder Verkehr noch eine Route, einen aktiven Cross-Connect oder einen Servicevertrag. Ein Kartenzeichen sagt aus, dass ein Facility-Eintrag in der gewählten Ergebnismenge steht. Daraus folgt nicht, dass ein bestimmtes Netz dort einen geschalteten Port besitzt, dass die Parteien den Austausch von Verkehr vereinbart haben, eine Route ausgewählt wurde oder heute Kapazität verfügbar ist. Die Karte erleichtert die Vorauswahl; sie macht aus einem Verzeichniseintrag keine betriebliche Verbindung.

Eine wiederholte Abfrage ist kein eingefrorener Datenstand

Copy API Query übernimmt die Suchformel in eine Anfrage. Damit lässt sich die Filterlogik wiederholen. Nicht zugesagt ist, dass PeeringDB die Einträge archiviert, die zum Zeitpunkt der Suche passten, oder eine unveränderliche Datenversion bereitstellt. Bei einer Designentscheidung, Beschaffung oder späteren Störungsanalyse ist dieser Unterschied entscheidend. Wer eine Entscheidung nachvollziehen will, sollte Zeitpunkt, Parameter, gespeicherte Antwort und die Rückfragen an die verantwortlichen Dateneigentümer gemeinsam dokumentieren.

PeeringDB beschreibt sich als gemeinschaftlich getragene, von Nutzern gepflegte Datenbank und als Ausgangspunkt für Entscheidungen zur Interconnection. Die Datenbesitzrichtlinie erwartet, dass Organisationen ihre Angaben aktuell halten, und beschreibt das Vorgehen bei strittigen Einträgen. Freiwillige Validierung und Pflege durch die Nutzer gehören zu diesem Modell; sie sind keine Garantie, dass jeder Datensatz für eine konkrete Planung auf dem neuesten Stand ist. Die praktische Grenze bleibt daher klar: Die Suche findet Kandidaten. Netze, Exchanges, Facilities und die jeweiligen Gegenparteien müssen die aktuelle Lage bestätigen.

Auch die API-v3-Diskussion ist davon zu trennen. Im September-Update bezeichnet PeeringDB das v3-Dokument als Diskussionsvorlage, zu der vor einer weiteren Ausarbeitung und möglichen Umsetzung Rückmeldungen eingeholt werden sollen. Es geht um die Architektur für Lesen und Schreiben sowie effizientere Abfragen. Copy API Query ist dagegen eine laut demselben Update bereits ausgelieferte Funktion der Advanced Search. Eine vorhandene Bedienhilfe ist kein Beleg dafür, dass die neue API bereits in Betrieb ist.

Automatisierung braucht eine anschließende Prüfung

Der bessere Ablauf hält drei Schritte auseinander: Advanced Search stellt eine Kandidatenmenge zusammen; die kopierte Abfrage macht die Filter überprüfbar und wiederverwendbar; die Karte vermittelt die Lage der Facilities in der Stadt. Danach müssen die Fakten geprüft werden, die eine Betriebsentscheidung tragen: Sind die Angaben zum Standort aktuell? Bestätigt das Netz seine Präsenz? Wie ist der Status von Port und Cross-Connect? Sind die Servicebedingungen vereinbart?

Diese Trennung schützt beide Seiten. Bessere Suche vermeidet unnötige Analysearbeit und macht Bedingungen leichter teilbar. Eine ausdrückliche Prüfung verhindert, dass eine praktische Oberfläche als Betriebsfreigabe missverstanden wird. Ein Eintrag beschreibt einen gemeldeten Zustand; er verbindet keine Netze. PeeringDB hat den Weg von der Suche zur Automatisierung verkürzt. Für die resultierende Verbindung bleibt der Betreiber verantwortlich.

Quellen