Command Line Client für REST-API: Programmiersprache

[paedubucher]

Bei meinem Arbeitgeber haben wir über die letzten Monate und Jahre eine Webapplikation komplett neu entwickelt. Der lang ersehnte Release soll noch in diesem Frühjahr erfolgen. Wir verwenden im Frontend Angular (JavaScript/TypeScript) und im Backend Java (Spring Boot). Die Applikation ist so aufgebaut, dass das Backend eine REST-API zur Verfügung stellt, die dann vom Frontend verwendet wird; was im Moment eben alle machen. Dazu kommen noch Mobile Apps für iOs und Android, welche die gleiche API verwenden.

Zum Testen/Debuggen der API verwenden die meisten Entwickler Postman, wobei ich hingegen curl bevorzuge. Da sich bei mir in den letzten anderthalb Jahren ein Repository mit verschiedensten Skripten angesammelt hat (Access-Token holen, abspeichern, Endpoint X/Y/Z damit aufrufen, etwas auswerten, usw.), und es den anderen Entwicklern mit ihren Postman-Sammlungen nicht anders geht, bin ich mit folgendem Vorschlag zur Geschäftsleitung gegangen: Wir schreiben einen Command Line Client für unsere API, der diesen ganzen Wildwuchs vereinheitlicht. Obendrein wird das als OpenSource-Projekt auf GitHub gemacht, sodass technisch versierte Kunden erstens sehen, wie man unsere API verwendet (Dokumentation ist schön und, Demonstration aber noch besser), und zweitens auch Prozesse damit automatisieren können. Obwohl da kein einziger Informatiker in diesem Gremium sitzt, konnte ich die Geschäftsleitung von dem Unterfangen überzeugen. Ich darf im Sommer einen Prototypen dafür bauen Wenn der dann gut ankommt, kann ich den im Herbst im Rahmen eines Studienprojektes weiterentwickeln. (Bis zum ersten Release soll also ich komplett alleine daran arbeiten.)

Nun ist die Frage, in welcher Programmiersprache ich das machen soll. Ich neige stark zu Go, könnte mir aber auch eine Umsetzung in Rust vorstellen. Meine Befürchtung ist aber, dass die anderen von mir eine Implementierung in Java erwarten, da dies bei uns schliesslich alle Backend-Entwickler können. (Ich wollte den Punkt noch nicht thematisieren, bevor ich mir eine Strategie zurechtgelegt habe.) Nun sehe ich folgende Argumente:

• Go ist offenbar für Kommandozeilenprogramme sehr gut geeignet, sonst wären docker (das CLI) und oc (OpenShift CLI), die bei uns im Einsatz sind, nicht damit geschrieben worden.
• Java erfordert die Installation einer JVM in der richtigen Major-Version. (Nicht alle unsere Entwickler sind Backend-Entwickler und haben das also nicht unbedingt installiert.) Go (oder Rust) erfordert nur ein einziges Binary und kein weiteres Setup.
• Niemand schreibt java -jar cli.jar ..., es bräuchte also Wrapper-Skripte (für Windows/macOS/Linux separat), damit die Parameter richtig gehandhabt werden.
• Go hat alles in der Standard Library, um damit einen REST-Client bauen zu können (http-Library, json-Marshalling, Library zum Parsen von Kommandozeilenargumenten). Bei Java ist man stärker auf externe Libraries angewiesen.
• Eine Java-Applikation dauert länger zum Starten. Wenn man längere Befehlsketten (über Pipes) mit mehreren iterativen Aufrufen (Listen abarbeiten) macht, könnte das schon träge werden.
• Für Java spricht, dass es andere Entwickler in der Firma schon kennen.
• Mache ich es in Go, könnte es so ausgelegt werden, dass ich die Firma von mir abhängig machen will. (Solche Andeutungen habe ich schon gehört.)
• EDIT: Bei einem Projekt, das auf GitHub gehostet wird, sollte man auch an die Aussenwirkung denken: Ich denke, dass man mit Go ein anderes Publikum anspricht als mit Java.

Nun mag die ganze Argumentation recht sophistisch klingen: Ich will es ja in Go und nicht in Java machen und suche bloss noch nach einer Bestätigung dafür. Andererseits würde es mich schon interessieren, ob meine Argumentation überzeugend und fundiert ist. Vielleicht wäre auch Java, Python, OCaml, Erlang, Fortran 66 oder Cobol 58 die ideale Sprache für das Problem, und ich bin bloss voreingenommen

Was meint ihr dazu? Hattet ihr schon ähnliche Projekte? Oder musstet ihr schon einmal eine solche Entscheidung vor einem nicht-technischen Gremium begründen? Oder wäre vielleicht der Weg über meine Entwicklerkollegen der Richtige (Absprache, Umfrage)?

[shoening]

Hallo,

ein paar Anmerkungen zu Deinem Problem:

• Es würde mich wundern, wenn die Entwickler alle nur mit Postman ihre REST APIs testen. Wenn die SpringBoot verwenden, dann gibt es da noch einige andere Möglichkeiten (über JUnit - auch remote); vor allen Dingen liefen die im wesentlichen automatisiert ab.
• Wenn Du eine Programmiersprache aussuchen willst, die dann auch Beispiele für die Kunden enthält, dann wäre vielleicht eine Umfrage bei den Kunden nicht schlecht
• Um REST APIs zu Dokumentieren bietet sich Swagger an.

Ciao
Stefan

[paedubucher]

Hallo,

ein paar Anmerkungen zu Deinem Problem:

• Es würde mich wundern, wenn die Entwickler alle nur mit Postman ihre REST APIs testen. Wenn die SpringBoot verwenden, dann gibt es da noch einige andere Möglichkeiten (über JUnit - auch remote); vor allen Dingen liefen die im wesentlichen automatisiert ab.
• Wenn Du eine Programmiersprache aussuchen willst, die dann auch Beispiele für die Kunden enthält, dann wäre vielleicht eine Umfrage bei den Kunden nicht schlecht
• Um REST APIs zu Dokumentieren bietet sich Swagger an.

Ciao
Stefan

Also wir verwenden nicht nur Postman und curl, sondern auch Unit- und Integrationtests. Aber manchmal möchte man halt auf einem bestimmten System ein bestimmtes Verhalten End-to-End testen, und dafür wird eben Postman/curl eingesetzt.

Im Moment haben wir nur Privatkunden, d.h. End-User. Firmenkunden kommen erst später dazu, d.h. da ist im Moment keine Umfrage möglich. Das CLI soll zunächst mal den Entwicklern in der Firma Zeit sparen, später auch den Kunden.

Unsere REST-APIs sind schon per Swagger dokumentiert. Das CLI-Tool ist halt eine ergänzende Veranschaulichung zu dieser Dokumentation, nicht deren Ersatz.

Aber Danke für die Anmerkungen, ich hatte da wirklich ein paar Sachen nicht erwähnt, die zum Verständnis wichtig gewesen wären

[heisenberg]

Auch mal eher so unsortiert meine Gedanken dazu - eher als Benutzer:

Erfahrungen mit verschiedenen API/Kommandozeilen Clients als User:

• Proxmox API Client
  Den fand ich schon immer unauffällig, schnell, fehlerfrei und angenehm zu benutzen. Proxmox verwendet da ein Perl 5 mit OOP dahinter. Perl 5 will ja eigentlich kaum einer mehr mit der Kneifzange anfassen. Ich verwende das auch so gut wie gar nicht. Wenn man Module kompilieren muss, dann kann Perl 5 eher anstrengend werden. Das was für mich Proxmox da abliefert ist für mich da echt eine Aufwertung von Perl 5. Perl 5 hätte auch wohl den Vorteil, dass das langfristig eher wartungsarm ist, weil die Sprache da eher stabil ist und keinen großen Umwälzungen mehr unterworfen. Der Kommandozeilen Der Kommandozeilen API-Client ist da ein Ein-Zeilen-Wrapper, der einfach nur den API-Call an das entsprechende Perl-Modul der API weitergibt.
• OpsCode Chef: Knife
  Knife ist das Kommandozeilenwerkzeug von Chef(Serverorchestrierung). Es ist zum einen eher lästig, weil es sehr bloatig erscheint. Es braucht, vor allem wenn die ganzen Bibliotheken, die es so lädt noch nicht im Cache sind schon mal 10-20 Sekunden bis es mal einen Befehl ausgeführt hat. Andererseits ist es sehr einfach erweiterbar. Man kann sehr schnell mit Ruby eigene Subkommandos/Unterfunktionen dazu entwickeln. Weiterhin fällt mir Ruby dadurch auf, dass ich schon desöfteren Schwierigkeiten bei Upgrade-Prozessen hatte. Ein altes Gitlab zu aktualisieren, war mir z. B. nicht möglich, weil ständig irgend etwas anderes in Sachen Ruby Libs gebrochen ist.

Ansonsten fänd' ich Java auf der Kommandozeile echt nervig. Wegen der Grösse der Java-Runtime. Wegen eines wahrscheinlich langsamen ausgeführten Kommandozeilenclients. Weil ich mangels Wissen da wahrscheinlich selbst auch nichts anpassen könnte.

Wenn man etwas für die "Community" schreiben will, und denen selbst auch Erweiterungen erleichtern möchte, bieten sich auch Programmiersprachen an die man dort erwarten würde. Also Ruby, Python, ...

Bei Go irritieren mich die riesigen Binaries etwas. kubectl von Kubernetes z. B. ist da 170 MB gross. Es ist auch langsam und braucht beim ersten Aufruf(ohne Cache) schon mal 5 Sekunden hier. Allerdings ist die Aufgabe hier ja übersichtlich, so dass das hier wahrscheinlich nicht so ins Gewicht fallen wird.

Rust und Go fände ich auf jeden Fall sehr interessant, weil das neue Interessante Programmiersprachen sind, wo ich selbst auch gerne mal reinschnuppern würde. D. h. ich kann mir vorstellen, dass das bei anderen auch Interesse und Neugier weckt. Wenn man die Compilerumgebungen da recht einfach installiert bekommt, ist das bestimmt eine gute Wahl.

[novalix]

Die ideale Programmiersprache für jegliches Problem ist immer Common Lisp. *scnr*

Ich habe gar keine Ahnung (praktische Erfahrung) mit Go. Es scheint aber so, dass da eine große Entwicklergemeinde dranhängt. Dementsprechend sollte Deine Aufgabe damit gut umsetzbar sein.
Ich nehme an, dass die Größe der Binaries damit zu erklären ist, dass darin die Runtime einkompiliert ist, weil man nicht davon ausgehen kann, dass diese sich auf jedem Zielsystem befindet bzw. befinden sollte.
Man kann zwar je nachdem bei der Kompilation eines solchen Binary den Baum schütteln, aber der Umfang bleibt trotzdem beachtlich.

In dieser Hinsicht hätte imho python die größten Vorteile. Wobei ich keine Ahnung habe, wie sich das bei Windows verhält. Nutzen ja auch einige.

Zu Java Programmen auf der Kommandozeile wurde glaube ich schon alles gesagt.
Und unter den Gründen, warum man Java verwendet, ist "kennen nichts anderes" wohl der doofste.

Ich würde sagen: Go for Go/Rust oder nimm python.

[heisenberg]

Und unter den Gründen, warum man Java verwendet, ist "kennen nichts anderes" wohl der doofste.

Die vorhandenen Fähigkeiten der Kollegen zu verwenden finde ich im Gegenteil sehr vorausschauend. Das ist u. a. der Grund für NodeJS: "Use the same language on the server side as on the client side." (Nicht dass ich damit sagen will, das ich Node irgendwie gut finde. )

[paedubucher]

Danke für die vielen Hinweise.

Etwas Perl-basiertes kommt kaum in Frage. Im Gegensatz zu Go kann das bei uns überhaupt niemand, und ich selber habe vor einigen Wochen mein einziges Perl-Buch in den Müll geworfen. Es war ein symbolischer Akt, und ich wollte damit ausdrücken, dass ich diese Sprache nicht mehr lernen möchte in meinem Leben. Perl 5 ist AFAIK dead-end, und Perl 6 wird wohl kaum gegen Python, Ruby etc. bestehen können.

Ruby kenne ich auch nur marginal. Im Gegensatz zu Perl würde ich das gerne mal verwenden, aber damit haben wir wiederum das gleiche Problem wie bei Go: niemand sonst kennt es. Ausserdem erfordert es eine installierte Runtime.

Python verwende ich regelmässig, meine Mitarbeiter kennen es aber praktisch gar nicht. Auch hier besteht das Problem mit der Runtime.

Die Grösse der Go-Binaries sehe ich auch als problematisch an. Wir verwenden OpenShift, das noch einmal ein paar Schichten auf Kubernetes draufpappt. Da sind die Binaries natürlich riesig. Ein Programm, das jedoch nur von der Standard-Library Gebrauch macht (was eines meiner Ziele ist), sollte da doch kleiner ausfallen. Ich hatte mal einen Command Line Client für die Oxford Dictionary API geschrieben (ox). Der wiegt stolze 7 MB. Wenn man aber bedenkt, dass da wirklich die ganze Runtime schon drin ist, relativiert das die Sache wieder.

LISP wäre natürlich schon eine interessante Option, aber da müsste ich mich mal ordentlich mit der Sprache befassen