API und Integrationen

Was diese Kategorie abdeckt

Vier verwandte Aufgaben liegen hier. Anfragen von Hand bauen und testen. Eine Schnittstelle dokumentieren, damit andere sie nutzen können. Ein Gateway vor mehrere Dienste setzen, damit Schlüssel, Ratenbegrenzungen, Kontingente und Versionen überall gleich funktionieren. Daten zwischen Produkten bewegen, die nie dafür gedacht waren, miteinander zu sprechen.

Die ersten drei sind für Teams, die eine API ausliefern. Die vierte ist für alle, die zugekaufte Tools zusammenflicken. Beide Zielgruppen landen in diesem Regal, weshalb die Produkte so verschieden aussehen.

Rein visuelle Automatisierung ganz ohne Code gehört zu No-Code und Automatisierung. Alarme für einen laufenden Dienst sind Monitoring.

Clients und was sie heute unterscheidet

Jeder Client sendet eine Anfrage und zeigt eine Antwort. Die Unterschiede liegen weiter hinten.

Zuerst die Umgebungsverwaltung: lokal, Staging, Produktion und was immer ein Kollege auf dem Laptop laufen lässt, sauber umschaltbar, ohne dass jemand eine URL von Hand ändert. Dann Skripting, damit ein Token vor einer Anfrage geholt wird, statt jeden Morgen eingefügt zu werden. Dann Test-Assertions, damit aus einer Collection etwas wird, das ein Build-Server ausführen kann.

Bei der Zusammenarbeit gehen die Meinungen auseinander. Cloud-Sync ist bequem und legt Ihren Anfrageverlauf auf fremden Servern ab. Dateibasierte Tools halten Collections im Repository neben dem Code, sodass sich eine Änderung wie jede andere prüfen lässt und kein Workspace mit einem ausscheidenden Mitarbeiter verschwindet.

Fragen Sie in beiden Fällen, wo Geheimnisse liegen. Ein in eine exportierte Collection geschriebener Schlüssel ist der Standardweg in ein öffentliches Repository.

Dokumentation, die nicht verrottet

Handgeschriebene Dokumentation ist nach einem Quartal veraltet. Die einzige Anordnung, die überlebt, ist die Erzeugung aus einer Spezifikation, die beim Code liegt und beim Merge neu gebaut wird.

Prüfen Sie drei Dinge: ob das Produkt Ihr Spezifikationsformat ohne Umwandlungsschritt liest, ob sich Beispiele direkt von der Seite ausführen lassen und ob alte Versionen für die weiterhin Nutzenden veröffentlicht bleiben.

Ein Changelog zählt mehr als Design. Nutzer müssen wissen, was wann kaputtging, und kein Styling ersetzt das.

Gateways und wann sich eines lohnt

Ein einzelner Dienst braucht selten ein Gateway. Der Fall tritt ein, wenn Authentifizierung, Ratenbegrenzung, Kontingente und Versionierung über mehrere Dienste identisch funktionieren müssen.

Dann lauten die Fragen: Wo läuft es und wie viel Latenz kommt dazu, wie werden Limits definiert und was sieht ein Aufrufer, wenn eines greift, lassen sich Schlüssel ohne Ausfallzeit rotieren und was steht in den Protokollen. Alles, was Traffic terminiert, wird zu einem eigenen Verfügbarkeitsrisiko. Fragen Sie also, was passiert, wenn das Gateway selbst einen schlechten Tag hat.

Was die Preise messen

• Nutzerplätze bei Clients und Dokumentationsprodukten, für reine Prüfer manchmal kostenlos.
• Tasks oder Läufe bei Integrationsplattformen, pro Schritt gezählt statt pro Workflow.
• Aufrufe oder Bandbreite bei Gateways, mit separatem Satz für alles, was aus dem Cache kommt.
• Aufbewahrung des Laufverlaufs, die in Einstiegstarifen kurz ist, und zwar genau dann, wenn Sie ihn brauchen.
• Konnektoren, wobei die Premium-Varianten eine Stufe über dem angebotenen Tarif liegen.

Task-Preise verdienen eine Rechnung vor der Unterschrift. Ein Workflow mit sechs Schritten, der alle zehn Minuten läuft, ist nicht ein Task im Monat, und die Zahl, zu der er wird, hat viele Teams überrascht. Dieselbe Art von Überraschung in anderen Kategorien ist in was Preisseiten verschweigen gesammelt.

Was Sie testen sollten

Bauen Sie eine echte Integration nach, die Sie schon betreiben, von Anfang bis Ende, einschließlich des Teils, in dem die Gegenseite einen Fehler zurückgibt.

Beobachten Sie, wie das Tool mit Wiederholungen, doppelter Zustellung, einem hängenden Drittsystem und einer Nutzlast mit fehlendem Feld umgeht. Gut gebaute Produkte lassen Sie einen fehlgeschlagenen Lauf nach der Behebung der Ursache wiederholen. Schwächere verlieren ihn stillschweigend und sagen nichts, bis es ein Kunde tut.

Prüfen Sie dann den Ausstieg. Collections, Spezifikationen und Workflow-Definitionen sollten sich als lesbare Dateien exportieren lassen. Was in einem Workspace eingeschlossen ist, ist Arbeit, die Sie zweimal machen.

Dokumentation, Versionierung und Nutzer behalten

Eine Schnittstelle mit Nutzern ist ein Versprechen, und der größte Teil der Schwierigkeit in dieser Kategorie entsteht dadurch, sie zu ändern, ohne dieses Versprechen zu brechen.

Legen Sie ein Versionierungsverfahren fest, bevor der erste externe Nutzer kommt, denn ein nachträgliches Verfahren heißt, alle auf einmal um eine Änderung zu bitten. Egal welches Schema: Veröffentlichen Sie, was sich wann geändert hat, und setzen Sie eine Übergangszeit an, die in Monaten gemessen wird, nicht in Wochen.

Fehler verdienen so viel Aufmerksamkeit wie Erfolge. Eine Antwort, die sagt, was schiefging, welches Feld es verursacht hat und was als Nächstes zu tun ist, erspart mehr Supportanfragen als jede Menge Fließtext.

Lesen Sie dann Ihre eigene Dokumentation wie ein Neuling. Die schnellste verfügbare Verbesserung ist meist ein funktionierendes Beispiel oben auf der Seite statt einer Referenztabelle.