© Liashko/Shutterstock.com
Entwickler Magazin
Interdisziplinäre Methoden des API-Designs

Grundlagen schaffen

Auch wenn es einem gestandenen Knochen - der Autor dieser Zeilen zählt sich selbst mit Stolz dazu - weh tut: Die Zeiten der Unternehmen, die im Stil der aus den Abenteuern von Lucky Luke bekannten Firma ACME alles selbst machen, sind lange vorbei. Heute gedeihen primär jene Firmen, die ihre Dienste für Dritte zugänglich machen, um so eigene Entwicklungszeit einzusparen. Außer Frage steht, dass APIs hierbei mehr als hilfreich sind: Sie stehen im Zentrum dieser Bemühungen.

Tam Hanna


Beim Design von APIs denken Entwickler leider nur höchst selten darüber nach, welchen Einschränkungen die API-Nutzer-Beziehung unterliegt. In der Praxis beschränkt man sich normalerweise darauf, eine technisch gangbare Lösung zu finden. Wenn dann Themen wie Latenz der Kommunikation Eingang finden, ist dies beim durchschnittlichen Entwickler eine große Leistung.

Dieser Artikel bedient sich einer Analyse diverser akademischer Papers, um die interdisziplinären Methoden herauszufinden, die beim Design eines benutzerfreundlichen API helfen. Dies ist in der heutigen Zeit nämlich immens wichtig: Hassen Entwickler die von einem Unternehmen angebotene Programmierschnittstelle, so wandern sie zur Konkurrenz ab. Das kann auch sehr erfolgreiche Firmen treffen. So behaupten bis heute nicht wenige, dass der Untergang des Symbian-Betriebssystems unter anderem darauf zurückzuführen war, dass das API extrem schwierig und stellenweise geradezu entwicklerfeindlich (Stichworte Leaves, Deskriptoren) aufgebaut war.

Eine Frage der Herangehensweise

Die Arbeit an APIs ist insofern haarig, als sie als Entwickler davon ausgehen müssen, dass ein vergleichsweise kleiner Fehler – dies behauptet zumindest Michi Henning in „API: Design Matters“ – ob der „tausendfachen“ Verstärkung massive Konsequenzen entfaltet [1]: „Das Erzeugen eines schlechten API ist sehr einfach, während die Erzeugung eines guten API vergleichsweise schwierig ist. Leider können auch vergleichsweise unschuldige Designfehler massive Konsequenzen haben: Ein API wird nun mal nur einmal entwickelt, aber dann tausende Male genutzt.“

In den folgenden Schritten wollen wir – anfangs – davon ausgehen, dass es in Ihrem Unternehmen noch kein nach außen kommuniziertes API gibt und wir quasi mit einem „Clean Sheet“ beginnen können. Dies ist insofern vorteilhaft, als Sie in dieser Situation keine Rücksicht auf schon etablierten Code nehmen müssen. Insbesondere in großen Konzernen hat man diesen Luxus nur sehr selten. Das bei LG im Jahre 2014 veröffentlichte Paper „An API Design Process in Terms of Usability“ [2] ist insofern einzigartig, als die Koreaner, bösartige Zungen sprechen hier von mehrfach, mit einem vollkommen neuartigen API ankamen, um ihrem Rivalen Samsung im Smart-TV-Bereich endlich Land zu stehlen. Die Literaturrecherche der Koreaner ergab eine Gruppe von Parametern, die gemeinsam die Qualität eines API beschreiben. Sie finden sich kurz zusammengefasst in Tabelle 1 und folgen – zumindest im Grunde – aus der Logik. Im ...

Entwickler Magazin
Interdisziplinäre Methoden des API-Designs

Grundlagen schaffen

Auch wenn es einem gestandenen Knochen - der Autor dieser Zeilen zählt sich selbst mit Stolz dazu - weh tut: Die Zeiten der Unternehmen, die im Stil der aus den Abenteuern von Lucky Luke bekannten Firma ACME alles selbst machen, sind lange vorbei. Heute gedeihen primär jene Firmen, die ihre Dienste für Dritte zugänglich machen, um so eigene Entwicklungszeit einzusparen. Außer Frage steht, dass APIs hierbei mehr als hilfreich sind: Sie stehen im Zentrum dieser Bemühungen.

Tam Hanna


Beim Design von APIs denken Entwickler leider nur höchst selten darüber nach, welchen Einschränkungen die API-Nutzer-Beziehung unterliegt. In der Praxis beschränkt man sich normalerweise darauf, eine technisch gangbare Lösung zu finden. Wenn dann Themen wie Latenz der Kommunikation Eingang finden, ist dies beim durchschnittlichen Entwickler eine große Leistung.

Dieser Artikel bedient sich einer Analyse diverser akademischer Papers, um die interdisziplinären Methoden herauszufinden, die beim Design eines benutzerfreundlichen API helfen. Dies ist in der heutigen Zeit nämlich immens wichtig: Hassen Entwickler die von einem Unternehmen angebotene Programmierschnittstelle, so wandern sie zur Konkurrenz ab. Das kann auch sehr erfolgreiche Firmen treffen. So behaupten bis heute nicht wenige, dass der Untergang des Symbian-Betriebssystems unter anderem darauf zurückzuführen war, dass das API extrem schwierig und stellenweise geradezu entwicklerfeindlich (Stichworte Leaves, Deskriptoren) aufgebaut war.

Eine Frage der Herangehensweise

Die Arbeit an APIs ist insofern haarig, als sie als Entwickler davon ausgehen müssen, dass ein vergleichsweise kleiner Fehler – dies behauptet zumindest Michi Henning in „API: Design Matters“ – ob der „tausendfachen“ Verstärkung massive Konsequenzen entfaltet [1]: „Das Erzeugen eines schlechten API ist sehr einfach, während die Erzeugung eines guten API vergleichsweise schwierig ist. Leider können auch vergleichsweise unschuldige Designfehler massive Konsequenzen haben: Ein API wird nun mal nur einmal entwickelt, aber dann tausende Male genutzt.“

In den folgenden Schritten wollen wir – anfangs – davon ausgehen, dass es in Ihrem Unternehmen noch kein nach außen kommuniziertes API gibt und wir quasi mit einem „Clean Sheet“ beginnen können. Dies ist insofern vorteilhaft, als Sie in dieser Situation keine Rücksicht auf schon etablierten Code nehmen müssen. Insbesondere in großen Konzernen hat man diesen Luxus nur sehr selten. Das bei LG im Jahre 2014 veröffentlichte Paper „An API Design Process in Terms of Usability“ [2] ist insofern einzigartig, als die Koreaner, bösartige Zungen sprechen hier von mehrfach, mit einem vollkommen neuartigen API ankamen, um ihrem Rivalen Samsung im Smart-TV-Bereich endlich Land zu stehlen. Die Literaturrecherche der Koreaner ergab eine Gruppe von Parametern, die gemeinsam die Qualität eines API beschreiben. Sie finden sich kurz zusammengefasst in Tabelle 1 und folgen – zumindest im Grunde – aus der Logik. Im ...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang