API-Webservices für die Zukunft der Marktkommunikation

In der Energiewirtschaft ist der Begriff API allgegenwärtig und wird für die Übermittlung der Marktlokation zur Pflicht. APIs werden als Schlüsseltechnologie für die Marktkommunikation angesehen, um den Austausch zwischen Marktteilnehmern zu optimieren und den EDIFACT-Standard abzulösen. Doch was genau ist eine API und wie funktioniert sie? 

In der Energiewirtschaft gibt es keinen Termin oder keine Produktpräsentationen, die ohne den Begriff API auskommen. In der Marktkommunikation ist der API-Webdienst ab dem 06.06.2025 für u.a. den Prozess zur Ermittlung der MaLo-ID der Marktlokation verpflichtend anzuwenden. Dessen Prozessziel es ist, dem Energielieferanten die nötigen Informationen für eine Belieferung vom Netzbetreiber zu bereitzustellen. Weitere Prozesse der Marktkommunikation sollen diesem Beispiel folgen. 

Die Maßgabe ist, dass API zunehmend EDIFACT ersetzen soll. Bis zur Einführung des MaBiS-Hub ist der ausdrückliche Wunsch des BDEW und der BNetzA für die Kommunikation zwischen den Marktrollen, Messstellenbetreiber (MSB), Lieferant (LF), Netzbetreiber (NB) auf die API-Technologie zurückzugreifen. Genau unter diesen Gesichtspunkten ist es erfolgsentscheidend, allen Marktteilnehmenden dasselbe Grundverständnis von dieser Zukunftstechnologie API zu vermitteln.

Eine API (Application Programming Interface) – oder Programmierschnittstelle – ist eine Sammlung von Regeln und Protokollen, die es Softwareanwendungen ermöglichen, miteinander zu interagieren und Daten, Funktionen sowie Funktionalitäten auszutauschen.  

APIs bestehen aus verschiedenen Definitionen und Protokollen, die zur Entwicklung und Integration von Anwendungssoftware verwendet werden. Sie dienen als Schnittstelle, die es unabhängigen Anwendungen ermöglicht, miteinander zu kommunizieren und Informationen auszutauschen. Damit ist API eine Schnittstellentechnologie, über die eine synchrone Kommunikation mit definierten Anfangs- und Endpunkten aufgebaut werden kann.

Die API-Kommunikation funktioniert wie ein Dialog zwischen einem Client und einem Server. Der Client sendet eine strukturierte Anfrage, und der Server antwortet mit einer ebenso strukturierten Antwort. Die API fungiert dabei als Vermittler, der die Interaktion zwischen beiden ermöglicht. Dieser Dialog muss so standardisiert werden, dass er von allen Beteiligten auf die gleiche Weise benutzt wird.

Die API-Guideline kann als ultimatives Regelwerk verstanden werden. Die EDI@Energy API-Richtlinie für Web-APIs ist wie ein Set von goldenen Designprinzipien, die sicherstellen, dass jeder die beste Erfahrung mit webbasierte APIs macht. Mit diesen Richtlinien entsteht eine API-Landschaft, die so konsistent und intuitiv ist, dass sowohl Anbieter als auch Nutzer von Web-APIs sie im Handumdrehen meistern können.

Im Allgemeinen helfen APIs und die dazugehörigen Guidelines dabei, eine widerspruchsfreie und effiziente Nutzung der APIs innerhalb des Unternehmens zu gewährleisten und die Zusammenarbeit zwischen verschiedenen Teams zu erleichtern. Klassische Beispiele für Unternehmen, die eigene APIs verwenden sind Adidas, Zalando, Google oder auch Otto. 

In der Welt der API-Guidelines gibt es einige wichtige Regeln, die sicherstellen, dass alles reibungslos läuft. Diese Regeln betreffen Konsistenz, Versionierung, Datentypen und JSON-Standardisierung, die Bestandteile eines jeden API-Webdienstes, HTTP-Status-Codes, Response-Codes, Objekte und das Bekanntmachen von Änderungen. Einige dieser Festlegungen sind zum Beispiel:  

• Änderungsmanagement 

  Bei der Versionierung geht es darum, dass nur kompatible Änderungen vorgenommen werden. Das bedeutet, es können keine neuen Pflichtfelder eingeführt werden, die das Gesamtkonstrukt beschädigen könnten. Fehlerbehebungen sind erlaubt, aber nur, wenn sie das Konstrukt stabiler machen. Nicht zulässig ist beispielsweise das Einführen eines neuen Pflichtfelds. 

• Konsultationsdokumente 

  Änderungen werden durch eine offizielle Mitteilung der Beschlusskammern 6 und 7 der BNetzA veröffentlicht. Diese Mitteilung legt die neuen Regeln fest und ab wann sie gelten. 

• Abwärtskompatibilität 

  Eine Änderung ist kompatibel, wenn etablierten API-Versionen weiterhin verwendet werden können. Ein Beispiel ist das Hinzufügen eines optionalen Parameters. Der API-Anbieter muss sicherstellen, dass alles reibungslos funktioniert, auch wenn vorherige Versionen diesen Parameter nicht verwenden. Dagegen wird Aufwärtskompatibilität nicht unterstützt.  

• Datentypen und JSON-Standardisierung 

  Diese sind klar definiert, um sicherzustellen, dass alle Daten im gleichen Format vorliegen. Es ist wie eine einheitliche Sprache, die alle verstehen. 

• Bestandteile eines API-Webdienstes 

  Wichtige Felder wie „TransactionID“ und „creationTime“ sind verpflichtend, um die Idempotenz sicherzustellen. Das bedeutet, dass eine Operation, wenn sie mehrmals ausgeführt wird, immer das gleiche Ergebnis liefert und den Zustand des Systems nicht verändert. Es ist wie ein Trick, der immer gleich funktioniert, egal wie oft er gezeigt wird.

Entscheidend für die Kommunikation ist die Authentifizierungsstelle in Form einer SubCA und des Verzeichnisdienstes. Die Rolle des Verzeichnisdienstes wird hierbei von dezentral organisierten Anbietern wahrgenommen.  

Vorbedingung

1. Der Marktteilnehmer A (z.B. NB) beantragt ein eigenes EMT.API Zertifikat über CSR bei einer SubCA.  

2. Die SubCA übermittelt dem Marktteilnehmer A (NB) das ausgestellte EMT.API Zertifikat und hinterlegt es in seinem LDAP-Verzeichnis.  

3. Der Marktpartner (LF) speichert seine API-Endpunkte für die Marktkommunikation in seinem API-Verzeichnisdienst ab.  

4. Sofern der LF noch kein EMT.API Zertifikat des Marktteilnehmers A (NB) hat, fragt er dieses über das LDAP-Verzeichnis der SubCA ab. 

   • Der LF schickt eine Anfrage zu dem EMT.API Zertifikat einer Marktpartner-ID über das LDAP-Verzeichnis an die SubCA 

   • Anhand der Marktpartner-ID ermittelt die SubCA das zugehörige EMT.API Zertifikatstriple an den LF 

Start des Prozesses Ermittlung der MaLo-ID

1. Der LF liest die URL zum API-Verzeichnisdienst des NB aus dem EMT.API-Zertifikat aus 

2. Die Abfrage des API-Endpunktes beim Verzeichnisdienst für den Marktprozess erfolgt  

3. Jetzt ist der LF in der Lage über API-Webservice mit dem NB zu kommunizieren 

Die Kommunikation funktioniert nur, wenn beide (LF & NB) SM-PKI Zertifikate haben.