Ich stecke gerade in einem kleinen API-Dilemma fest und frage mich, ob andere ähnliche Erfahrungen gemacht haben. In meinem aktuellen Projekt muss ich Daten aus einem veralteten System abrufen, das nur eine sehr rudimentäre REST-Schnittstelle anbietet. Die Dokumentation ist praktisch nicht vorhanden, und ich habe das Gefühl, ich rätsle mich nur durch Trial and Error voran. Besonders frustrierend ist der Umgang mit den Antworten bei Fehlern, die mal als Plain Text und mal als unstrukturiertes JSON kommen. Manchmal wünschte ich mir, ich könnte einfach eine ordentliche API-Schnittstelle etablieren, die konsistente Fehlermeldungen und eine klare Struktur liefert. Wie geht ihr mit solchen "Wildwuchs"-APIs um, bei denen man nie so recht weiß, was einen erwartet?
Ich kenne das Gefühl von Wildwuchs-APIs, wo man mehr raten als verstehen muss, und ja es zieht einen runter, aber irgendwo steckt auch ein ungefähres Muster darin.
Es hilft manchmal zu prüfen ob der Dienst eine minimale Semantik per Headers kommuniziert und wie Fehlertexte sich über Zeit entwickeln haben, also Muster in Statuscodes und Payloads zu suchen.
Manche Varianten der Fehlerausgabe wirken wie Prototypen aus unterschiedlichen Teams und deshalb ist eine konsistente Fehlerbeschreibung selten.
Wäre es sinnvoll eine schlichte Adapter Ebene zu bauen die alles in ein einheitliches Schema überführt oder dreht man sich damit nur im Kreis?
Vielleicht geht es nicht nur um Fehler sondern um Erwartungen der Nutzer und um eine spröde Schnittstelle die eigentlich resigniert und eine klare Geschichte braucht.
Ich frage mich ob der Konflikt wirklich gelöst wird durch Technik oder ob man die Realität akzeptiert dass Systeme nie perfekt standardisiert werden.
