mit Java API arbeiten

[runphp]

Hallo Leute,

Ich wollte mich mit dem Thema API etwas vertraut machen und ein kleines Tutorial mit anschauen. Leider kapier ich nicht wie das ganze geht, da ich ein Token anfordern soll und da irgendwie was mit Javasciptcode steht. Vielleicht kann einer mir beim Einstiegt/Setup helfen. Hier der Link zum Video:

Mfg

 

[Marinek]

Deine Frage ist ihmo viel zu allgemein.

Man wird dich mit vielen Informationen versorgen müssen.

 

[M.L.]

Das ist Eclipse (?) mit via Maven heruntergeladenem Gson (Video ab 12:40 / 13:00 ), der API-Key und oder dessen Nutzung könnte langfristig monetarisiert werden. Der Java-Code an sich lässt sich danach via Auto-Vervollständigung reproduzieren.

Und etwas billiger könnten diese Tutorials sein: https://howtodoinjava.com/jersey-jax-rs-tutorials/ (spez. zu Gson)

 

[mihe7]

@runphp Du bringst hier ein paar Dinge durcheinander.

Als API bezeichnet man die (Spezifikation einer) Programmierschnittstelle eines Systems. APIs gibt es viele.

Das Betriebssystem hat eine API, die Java Platform hat eine API, Office Pakete bieten eine API an usw. APIs können auch über das Netzwerk bzw. das Internet angeboten werden. Heutzutage erfolgt die Kommunikation oft mit Hilfe von JSON-Dokumenten, die über HTTP(S) ausgetauscht werden. Das ist aber keineswegs die einzige Möglichkeit: SOAP oder RPC wären beispielsweise ebenfalls möglich.

In dem Video geht es um eine REST(ful)-API, wobei man hier aufpassen muss: REST ist nicht immer REST, sondern oft nur eine API, die auf HTTPS+JSON fußt und dann einfach als REST-API bezeichnet wird, was streng genommen falsch/irreführend ist, weil REST einen Architekturstil bezeichnet, der bestimmte Anforderungen an die API stellt. Das aber nur nebenbei, denn für den Request macht es praktisch keinen Unterschied, ob die Architektur nun wirklich RESTful ist oder nicht.

Wie also wird eine "REST-API" angesprochen? Ganz einfach mit Hilfe eines HTTP-Requests. Man sendet einen Request an den Server und erhält eine entsprechende Antwort. That's it.

HTTP kennt verschiedene Methoden (auch "Verben" genannt), wie GET, POST, PUT, DELETE usw. die in den APIs gerne verwendet werden, um zu unterscheiden, was mit den im Request angesprochenen Ressourcen geschehen soll.

Der Browser führt beim Öffnen einer URL z. B. einfach einen GET-Request durch. Beispielsweise kannst Du https://random-data-api.com/api/v2/beers?size=2 aufrufen und erhältst ein JSON-Dokument, bestehend aus einem JSON-Array mit zwei JSON-Objekten, zurück. Dokumentation der API unter https://random-data-api.com/documentation

Alles, was Du tun musst, ist in der Programmiersprache Deiner Wahl einen GET-Request abzusetzen. Zum Beispiel kannst Du in der JShell schreiben:

import java.net.http.*;
URI uri = URI.create("https://random-data-api.com/api/v2/beers?size=2");
HttpClient client = HttpClient.newHttpClient();
HttpRequest request = HttpRequest.newBuilder(uri).GET().build();
InputStream is = client.send(request, HttpResponse.BodyHandlers.ofInputStream()).body();

Jetzt hast kannst Du die Antwort aus dem InputStream lesen, z. B. um das darin enthaltene JSON zu parsen. Dafür verwendet man dann eine Lib wie Gson oder org.json oder json-simple oder ...

Zur Ausgabe auf dem Bildschirm reicht aber auch erstmal ein

is.transferTo(System.out);

Natürlich sind die APIs oft nicht so trivial wie die eben gezeigte. In der Regel erfordern sie Authentisierung und auch die Verwendung der API kann ziemlich komplex sein. In den Fällen gibts aber oft Bibliotheken, die einem das Leben erleichtern.

 

[M.L.]

Teil II: zum Thema API-Design gibt es demnächst ein Video bei Youtube, Kanal "thenativeweb", "API-Design: Das einzige Video, das du brauchst // deutsch"
-> youtube.com/watch?v=SexQcBUp3DM (den Kanal kann man auch für Informationen zum Thema (Rest-)API verwenden)

 

[distinct]

Nun die Frage aller Fragen: Was war zuerst da, die API oder das Programm?

 

[Neumi5694]

Nun die Frage aller Fragen: Was war zuerst da, die API oder das Programm?

Das ist sogar einfach zu beantworten. Ohne zu wissen, welche Befehle ein Rechenkern oder auch nur eine Schaltung hat, kann man auch nicht programmieren. Man kann keine Boolean-Berechnung machen, ohne zu wissen, welche Operationen es gibt. Und Boolean ist der Grundbaustein aller Operationen, deshalb würde ich sagen die Definition, also API, kam zuerst.

 

[mihe7]

Teil II: zum Thema API-Design gibt es demnächst ein Video bei Youtube, Kanal "thenativeweb", "API-Design: Das einzige Video, das du brauchst // deutsch"
-> youtube.com/watch?v=SexQcBUp3DM (den Kanal kann man auch für Informationen zum Thema (Rest-)API verwenden)

Hm... das ist ein Livestream mit Zwischenfragen, von denen gefühlt 95 % rein gar nichts mit der API zu tun haben. Die Informationsdichte des Videos ist entsprechend niedrig, da wären Links zu den interessanten Teilen im Video nicht verkehrt.

 

[M.L.]

Informationsdichte ... niedrig

(offtopic) es ist aber auch ein (evtl. (un)geplantes) Beispiel für "mit Leuten reden" oder "people factor" um Software (z.B. als API) zu entwickeln

 

[mihe7]

(offtopic) es ist aber auch ein (evtl. (un)geplantes) Beispiel für "mit Leuten reden" oder "people factor" um Software (z.B. als API) zu entwickeln

Ja, für "mit Leuten reden" ist das tatsächlich ein Beispiel. Ich will nicht ausschließen, dass das Video den Leuten gefällt, und es ist von mir auch nicht bös gemeint, aber mir persönlich ist das einfach viel zu langatmig.

Inhaltlich gehts los bei

los und bis 10:37 ist auch ok, das sind vier Minuten.

Dann drei Minuten (bis 13:33) Erklärung, warum man welches Beispiel nicht genommen hat, um dann "Bibliotheksverwaltung" einzuwerfen und auszuschweifen, dass man als Kind in einer Bibliothek Bücher ausgeliehen hat und das doch für ihn das Interesse an Bibliotheken durch das Internet zurückgegangen sei aber doch grundsätzlich jeder wissen sollte, wie so eine Bibliothek funktioniert. Aha.

Ab 14:13 werden eine halbe Minute lang Chatnachrichten vorgelesen. Dann wieder "Bibliotheksverwaltung" - ein Satz! Bevor erstmal wieder auf die Chatnachrichten und dort insbesondere auf den Eistee eingegangen wird. Jetzt muss ein Glas gezeigt werden und ein Strohhalm, der - ganz wichtig - ein Metallhalm ist... Danach Kanalwerbung, gut, muss auch sein.

Ab 17:17

gehts dann endlich los, jetzt aber wirklich oder? Nöööö.... Erst muss man sich eine halbe Minute lang erklären lassen, dass man einen leeren Editor offen hat und man eine README.MD bearbeitet.

Also weiter zu 17:47. Whoa, 10:37 bis 17:47, das sind 10 Minuten mit absoluter Null-Info.

Die nächsten Minuten sind dann gut, wenngleich mir da auch zu viel Zwischengeplänkel ist (Wie viele Bücher hat wohl eine Bibliiothek? Sind "Die drei ???" spannend? Oder die Zwischenfrage eines Users wie man den Co-Pilot aktiviert usw.)

Bei 35:46 gehts dann an den Code... Meint man, denn erstmal gehts um Go. Dann ab 39:51 (also gute 4 Minuten später), wird dann sogar echter Code geschrieben. Natürlich wieder mit Infos zu Go... Um 53:46, also knapp 14 Minuten später, hat man dann auch schon einen Ping-Service.

Dann Refactoring inkl. Go-Erklärungen, bis 1:12:51, dann heißt es "Wir hatten gesagt: das erste, was wir mal machen müssten, ist wir wollen als Bibliothek überhaupt mal neue Bücher hinzufügen". Jetzt gehts endlich mal wieder um die API. Aber natürlich nicht, ohne Ausschweifungen z. B. darüber, was im Schach ein Halbzug ist und dass es eine Lücke in den Schachregeln gab usw. über sich ergehen lassen zu müssen.

Da habe ich es dann aufgegeben. Im Real-Life gibts ja auch Laber-Meetings - wenn auch nicht ganz so extrem - da verabschiede ich mich regelmäßig, wenn es geht und sich das nicht in eine andere Richtung lenken lässt Das Schlimme ist ja, dass sich selbst fachlich noch stundenlang diskutieren lässt.