Viel Spaß damit

Falls du mal SOAP im Bezug auf Alcatel oder Cisco hörst: Da ist bis jetzt alles prima :)

Gruß
Daniel

Das Error-Handling ist auch gleich mit drin.

Und ich stimme dir zu: Man könnte auch mit SOAP saubere, verlässliche und gut dokumentierte APIs bauen, gar keine Frage. Einige tun das bestimmt auch. Auch wenn mein Rant – der natürlich ohne Frage auch von aktuellem Frust geleitet wurde – das unterschwellig nahelegt: Ich tendiere normalerweise gar nicht so sehr dazu, Dinge aufgrund der Wahl eines bestimmten Protokolls, eines bestimmten Tools oder einer bestimmten Programmiersprache zu verurteilen.

Diese Unterkunftsgeschichte hier ist aber bei weitem nicht die erste SOAP-API, die zu implementieren ich das Vergnügen hatte, und ich kann so langsam nicht mehr abstreiten, dass sich ein gewisses Muster zeigt: Alle waren schlecht designed, alle hatten schlechte Dokumentation und bei allen hatte ich anbieterseitig mit Leuten zu tun, die völlige Ahnungslosigkeit demonstrierten. Ich meine, wenn ich einen SOAP-Fault mit einem 25-zeiligen Java-Stack-Trace bekomme, der mir in keinster Weise sagt, was dem Server nicht gepasst haben könnte, und die Antwort des Dienstleisters ist dann „ähm, hm, ja, also, probieren Sie doch mal, was passiert, wenn Sie \r\n als Zeilenumbrüche übermitteln“ (was dann nebenbei nicht mehr spezifikationskonform wäre), dann frage ich mich schon, ob man auf Basis einer solchen API wirklich ein Geschäftsmodell aufbauen möchte. Kurz gesagt, es entsteht bei mir mehr und mehr der Eindruck, dass die wirklich fähigen Leute tendentiell eben eher zu anderen Protokollen als ausgerechnet zu SOAP greifen.

Ich habe hier inzwischen eine ziemliche Abdeckungsskala, am unteren Ende mit beispielsweise einer kleinen regionalen Agentur (wie hier), in der Mitte zum Beispiel mit einem mittelgroßen Mobilfunkunternehmen, deren MMS-API auf Basis von SOAP/MM7 ich umsetzen durfte (das waren die mit dem „probieren Sie doch mal andere Zeilenumbrüche“) bis hin zu richtigen großen APIs wie zum Beispiel der Bürgerportal-Schnittstelle eines Bundeslands, die von T-Systems entwickelt wurde – bisher mein einziges Projekt, bei dem ich ernsthaft in Betracht ziehe, schlicht zu kapitulieren – vor allem, weil der „Support“ hier nur so funktioniert, dass man sich mit seinen Fragen an den zuständigen Sekretär im Ministerium wenden muss, der das dann so gelegentlich mal an T-Systems weitergibt. Aber das ist eine andere Geschichte.

Die meisten APIs sind allerdings ziemlicher Murks. Als Webentwickler hab ich tagtäglich mit allen Sorten von APIs zu tun. Auffallend ist dabei vor allem eins: Öffentliche APIs (z.B. von Web-2.0-Sites etc.) sind meist wesentlich besser als geschlossene B2B-Dinger. Das liegt wahrscheinlich daran, dass man bei öffentlichen APIs nen Ruf zu verlieren hat. Proprietäre sieht nur der arme API-Coder, der sich damit rumschlagen muss. Sei froh, dass man keinen NDA abverlangt hat, bevor du die Doku lesen durftest. Alles schon erlebt.

Meine Lieblings-API ist übrigens die, die bei der Übermittlung einer Adresse in Frankreich reproduzierbar eine Tomcat-„Uncaught-Exception“-Seite geschmissen hat. Stellte sich raus, es lag am Singlequote in „Rue d’Alsace“. Was das bedeutet, kannst du dir sicher denken…