Das heißt, es ist im Endeffekt auch wieder ne API. Geh mal mit deiner Anfrage oder Sie verrückst versichert sich erstmal bei Papa und frag diesen Service an und der sagt Nee abgelehnt Coding Body Time Podcast wohnt im Softwareentwicklung und aktueller Technews. Herzlich Willkommen. Herzlich Willkommen zur neuen Folge vom Coaling Buddies Podcast.
Es ist wieder soweit, es ist Donnerstag, eine neue Folge steht in der Tür und damit können wir jetzt auch starten und in diesem Sinne begrüße ich meinen Partner hier im Podcast, den Tino ganz herzlich, wie geht's dir? Moin Fabi, ja alles super bei mir.
Die Sonne scheint, ich habe sehr gute Laune muss ich sagen, weil du weißt ja wie das ist, wenn das Wetter wenn die Sonne strahlt, dann strahlt doch auch das innere Herz, oder wie sagt man irgendwie so eine Redewendung gibt es doch, wenn die Sonne strahlt und man drin sitzt es gibt. Nichts Schöneres. Es gibt nichts. Schöneres als Softwareentwickler als bei strahlender Sonne in der Bude zu sitzen und aus dem Fenster zu schauen.
Man sieht, wie glücklich alle draußen sind und man selbst ist glücklich, weil man drin bleiben darf. Aber ich finde das wirklich. Ich finde das wirklich lustig, weil ich freue mich echt immer, wenn das Wetter gut ist, irgendwie und auch wenn ich drin sitze. Also ich weiß nicht schön, kennst du das also? Keine Fenster aufmachen. Also leider was dickes.
Es gibt ja viele, die es da wirklich so raustreibt und ich mag es auch draußen, aber ich bin, muss ich ganz ehrlich zugeben, und das muss ich mich jetzt hier auch outen, ich hab kein Problem drin zu sein. Und ich find es aber trotzdem schön, wenn draußen dann schönes Wetter ist. Aber ich find es auch schön, wenn ich drin bin.
Dann also weißt du, ich denk mir nicht so oh tolles Wetter, ich muss jetzt unbedingt raus weil ich denk mir so ah Mensch tolles Wetter, es freut mich, dass es draußen tolles Wetter. Ja, bei mir ist es halt auch so, dass ich mir denke, ja, ist also wenn ich zum Beispiel noch vorhabe, später rauszugehen, keine Ahnung irgendwas, selbst was banales einkaufen, Kaffee trinken gehen oder irgendwas freue ich mich da drauf, aber ich finde es nicht schlimm, dass ich aktuell noch drin sein muss.
Sehr gut. Das ist die Richtige. Einstellung also das ist für mich kein Thema, weil ich kann ja später noch das Wetter genießen, aber es ist nicht so, auch wenn du jetzt zum Beispiel wir im Homeoffice arbeitest und die ganze Zeit rausguckst. Ich bin endlich raus. Habe ich auch nicht, das habe ich auch. Nicht das ist, das ist schon mal schön.
Und ich hoffe, meistens ist es ja sogar kühler in meiner Wohnung. Man wird es kaum glauben als draußen, wenn es jetzt so richtig warm ist draußen und dann ist es doch ganz angenehm, drin zu sein. Sehe ich auch so und ich hoffe auch, dass liebe Zuhörer, lieber Zuhörer, das ist auch gerade bei dir, schönes Wetter ist. Und ansonsten macht die Folge einfach nochmal an, wenn schönes Wetter ist. Genau. Hören Sie einfach mehrfach, das ist gar kein Problem.
Ok, schön offic, beendet Fabi. Hau doch mal raus. Was ist denn unser heutiges Thema? Unser heutiges Thema, Wir hatten ja letzte Woche in der Interview Folge mit Anthony und da ging es auch unter anderem um apis und da haben uns ja auch die ein oder andere Nachrichten erreicht. Und wir wurden gefragt, ob wir vielleicht einfach mal ne Folge machen können. Zum Thema API einfach mal allgemein, was sind Apis, wie funktionieren Apis? Also ich sag mal eine
übersichtsfolge über apis. Und genauso, also so mehr auf sag ich mal top Level Einsteiger mäßig. Genau, genau. Ich hoffe nicht cool, ich hoffe natürlich, dass sich trotzdem jeder und jede Hörerin hier noch was mitnehmen kann. Ja, und wenn es nur noch mal Revue passieren ist oder so. Auffrischen des Wissens ist. Genau find ich gut. Ja, dann hau doch mal raus. Wie wollen wir denn starten, wie wollen wir die Sache angehen,
hast du da schon Plan im Kopf? Ich würde mal erst mal gucken, dass wir uns oder dass wir betrachten, was eigentlich eine API an sich ist. Also wirklich so ein bisschen. Oberflächlich sage ich jetzt mal, dann gucken, warum es überhaupt sowas wie apis gibt und was es für Arten von apis gibt. Dann können wir weiter gucken und sagen okay, wie funktioniert denn überhaupt so eine API im allgemeinen und und vielleicht auch noch mal so.
Dabei auch noch so Praxisbeispiele angucken und vielleicht können wir noch mal gucken, dass wir vielleicht ein paar Tipps generieren, was bei Entwicklung von apis vielleicht ganz nett wäre, wenn man das vielleicht auch machen würde. Also quasi was so Punkte sind, die eine eine schlechte API von einer guten API unterscheiden am Ende.
Ja, also oder wenn wir jetzt zum Beispiel anfangen möchte und sagt, lass mal starten, ich möchte eine API entwickeln, wie fange ich da an, worauf muss ich achten, sowas in die Richtung können wir einfach mal improvisieren. Ja, da fällt uns etwas ein, genau, ich würde vielleicht mal ganz kurz anfangen mit. Einer gewissen allgemeinen Definition mal erstmal ganz richtig schön trocken, was überhaupt so eine API ist, damit wir jetzt auch wirklich nichts
Falsches erzählen. Also erstmal ist eine API an sich, das ist ja eine Abkürzung, das steht ja für Application Programming Interface und das ist mehr oder weniger eine Menge von Regeln und Definitionen, die Halt bestimmen, wie zum Beispiel Softwarekomponenten miteinander interagieren. Also du hast verschiedene Software Systeme. Und die müssen irgendwie Informationen nahtlos miteinander austauschen können. Und das ist, sag ich jetzt mal im groben die Definition einer API.
Ne, ja und? Also das heißt, du, das ist im Prinzip. Die Verbindungsstelle, um mehrere Anwendungen miteinander arbeiten lassen zu können. Also ich kann dir ja mal eine kleine Analogie geben. Ich finde Analogien, ich bin ja Fan von Analogien.
Da muss ich meine doch kurz loswerden, weil ich stell mir da, also man kann sich das halt wieso ein Puzzle vorstellen, du hast halt so mehrere Puzzleteile und du kannst sie ineinander setzen und jeder, ich glaube jeder hat schon mal Gepuzzelt im Leben, das halt auch gewisse Puzzleteile nur zusammenpassen, du kannst ja nicht jedes mit jedem verbinden und insgesamt ergibt es denn dein Bild, sozusagen deine Gesamtanwendung kann man sich das glaube ich schon mal auf ganz abstrakter
Ebene vorstellen. Also dass du sagst, du hast verschiedene Puzzleteile und die verschiedenen Puzzleteile sind verschiedene Teilsysteme innerhalb eines größeren Systems. OK, Mhm, ja. Und dann diese Nupsies, quasi die Miteinander passender. Das könnte dann deine AFI sein, aber kennst du dieses eine Teil im Puzzle was reinpasst und das stimmt aber eigentlich nicht. Ja genau, na ja gut, es passt ja nicht rein, sondern man denkt es
passt. Es passt so zu 95% und man hat halt keinen Bock mehr und drückt es dann einfach rein und sagt super, da habe ich es doch glatt gefunden, aber eigentlich ist es doch falsch. So possible man also gar nicht. Ach so, ok. Gut zu wissen also ich, ich schneide die immer ab und klebe es dann einfach alles
aneinander. Klassiker das ist sagt er und und sagt, das ist Kunst, weil man erkennt natürlich nichts, weil die nicht richtig sortiert, ich schneide immer, ich schneide immer Bilder auseinander und gebe es anderen und sage hier kannste puzzeln. Nein, also ich finde die Analogie auch nicht schlecht und wenn wir uns jetzt mal 2 Puzzleteile angucken, wie die ineinander passen. Dazu würde ich, hatte ich noch eine Analogie im Kopf.
Und zwar. Wenn du jetzt sagst, du gehst ins Restaurant ne und setzt dich dahin und möchtest jetzt zum Beispiel irgendwie n Essen bestellen, ne, das ist ja so der typische Anwendungsfall innerhalb eines Restaurants und dann kommt irgendwann der Kellner und Du sagst dem Kellner dann zum Beispiel ja ich möchte gerne die Nummer 250 haben und der Kellner sagt alles klar Nummer 250 geht dann in die Küche, in der Küche wird dann das Essen vorbereitet,
zurechtgemacht, gekocht. Nenn s wie du möchtest und dann kommt das natürlich wieder zurück an einen Platz und du bekommst was du haben möchtest. Das heißt im Endeffekt ist der Kellner an der Stelle die die Schnittstelle, also dieses Interface, also die API. Die zwischen dem Gast und der Küche agiert, sage ich jetzt mal. Ja, ja, und da kann man so sehen, ja. Und du kannst natürlich auch, weil es heißt ja Application pro Gramming. Na also du kannst.
Das bedeutet ja, dass du sie theoretisch auch verändern kannst. Die API, und das wäre halt, wenn du eine neue Speisekarte hast. Also wenn du sagst okay. Man setzt jetzt ne neue Speisekarte ein, dann ist die 250 vielleicht nicht mehr das, was es vorher war. Ne, also vorher war es vielleicht Kartoffeln mit Quark und jetzt ist es aber Spaghetti Bolognese, ne OK. Das heißt, die Speisekarte ist dann sozusagen auch die Dokumentation beziehungsweise die.
Die Vereinbarung zwischen Küche und Gast, dass wenn der Gast sagt, Ich möchte jetzt bitte über den Kellner die 250, also über unsere API die 250 bestellen, dass sowohl die Küche der Koch als auch der Gast das gleiche Verständnis davon haben, was gefordert ist und was geliefert werden muss.
Am Ende genau also nicht, dass der Koch noch die alte Speisekarte hat und guckt und sagt, hier Ach Quark, mit was hast du gesagt, Kartoffeln mit Quark und du erwartest eigentlich ne geile Pasta oder so. Die Richter. Das wär doof. Das aber ist n sehr cooles Beispiel, was es auch sehr gut verdeutlicht, gefällt mir sehr gut. Schön. Dein Puzzle mochte ich auch gerne. Das ist schön, viel mehr gibt es ja denn eigentlich auch gar nicht zu sagen, oder?
Ja, zum nächsten Mal. Aber wenn wir jetzt also, das ist ja jetzt auf einer sehr abstrakten Ebene, sehr, also so eine Analogie, wie gesagt, ich mag Analogien sehr gerne, auch wenn ich vielleicht nicht immer die besten wähle, aber gut, dass ich mal nein, aber wie sieht das Ganze denn jetzt zum Beispiel im auf mehr auf Software entwicklungsebene aus? Hast du da vielleicht ein Beispiel, was dir einfällt, wo du sagst okay angenommen, du hast wirklich Softwaresysteme,
die miteinander arbeiten? Hast du da irgendwie wollen wir das mal ein bisschen übertragen auf ein Beispiel. Ja, ja, ja, warte. Ja, wir können ja auch das Essensbeispiel nochmal nehmen, weil ich glaube, so ein Klassiker gerade unter Codern ist ja auch Essen bestellen, weil man einfach keine Zeit hat einzukaufen und zu kochen, weil man ist ja so dermaßen am Coden aktuell, wer kennt es nicht? Und das Ganze ist. Softwareebene gehoben, sage ich mal. Dein Beispiel wäre ja im Prinzip
bei einem. Lieferservice zu bestellen oder oder. Bei einem Dienst wie beispielsweise. Lieferando, Uber eats oder was es da alles gibt. Dann hast du ja im Prinzip genau das, den gleichen Ablauf, dass du im Prinzip sagst, OK, ich möchte jetzt essen bestellen, mir soll das jemand zubereiten und in dem Fall halt auch noch nicht nur an den Tisch bringen, sondern zu mir nach Hause und das klingt ja jetzt erstmal wie ein Service, das heißt, ich gehe zum Beispiel auf die Website
ich. Lokalisiert oder? Ich sage, in welcher Straße ich wohne, kriegt dann sage ich mal, verschiedene Restaurants angezeigt die Speisekarte, ich wähle was aus, ich kann das gleich bezahlen und sie wird mir wird angezeigt, dass es beispielsweise in 40 Minuten geliefert wird, genau so. Oftmals oder sehr, sehr wahrscheinlich. Sagen wir es mal so, stecken dahinter aber mehrere Applikationen, die vereinzelte
Aufgaben haben. Gehen wir zum Beispiel davon aus, man wird lokalisiert oder eingeordnet, wo man sich jetzt geografisch quasi gerade in der Stadt befindet, dann könnte das zum Beispiel so ein Lokalisierungsdienst sein oder Service, der denn beispielsweise an den zweiten Service, die GPS Koordinaten beispielsweise übermittelt und dann ein
anderer. Es quasi anhand von, ja, sagen wir mal in der Datenbank oder irgendwas entscheidet, welche Restaurants überhaupt in Frage kommen, die dir denn aufgelistet werden. Das könnte so eine Antwort sein, die du dann siehst. Die halt in der Nähe.
Sind ne genau die halt überhaupt für dich in Frage kommen, sozusagen weil das dafür brauchst du ja die Daten beispielsweise aus diesem Lokalisierungsservice, der sagt Hey Pass auf, du bist an Fleck a und dann willst du natürlich auch nur im Umkreis von x Kilometern sage ich mal einen. Lieferdienst sozusagen haben oder ein Restaurant, weil du willst ja jetzt nicht 5 Tage warten bis das Essen da ist. Schön von München nach Hamburg bestellen? Genau. Und so zieht sich halt die Kette
immer weiter. Dann willst du halt sagen okay, ich möchte jetzt bezahlen. Ja gut, wahrscheinlich wird der Service für die Lokalisierung oder auch der Service für die Anzeige deiner möglichen Restaurants sich nicht noch um die Bezahlung kümmern wollen, das heißt es wird noch eine dritte Anwendung geben, die. Diese ganze Payment Nummer, also
die Bezahlung abwickelt und. So zieht sich das immer weiter, dass du sagst, mein Service wie beispielsweise Lieferando, ich möchte jetzt Essen bestellen, bezahlen und geliefert bekommen, splittet sich halt in ganz ganz viele Teilsysteme auf, die dann quasi wie wir das mit dem Puzzle gesagt haben dann. Per API miteinander verbunden sind also kommunizieren.
Können also du hast quasi was Bezahlsystem ist ein so ein Puzzleteil und der Lokalisierungsservices ein Puzzleteil und so weiter ne und das ergibt dann. Das Bild also, das sind natürlich noch viel mehr. Das sind sehr abstrakte Beispiele, aber wenn ich diese Puzzleteile Zusammensetze, steht dann auf meinem Puzzle zum Beispiel lieferando, aber dann hast du halt so dieses Gesamtsystem am Ende, so kann man sich das vorstellen. Finde ich gut. Klingt auf jeden Fall mega.
Also ich ich könnte es mir jetzt vorstellen, weißt du das ist gut, das ist gut. Schwer um Kopf und Kragen gelegt. Ach was, ja genau. Und wenn man jetzt sagt okay, also da ergibt sich ja irgendwie schon ein bisschen die Frage, wieso gibt es überhaupt apis, was ich interessant finde, ist, dass apis überhaupt so ins Leben
gerufen worden, weil. Vor allem halt mit diesem ganzen sag ich mal Netz mit diesem ganzen Netzwerken zwischen Rechner. Das heißt, wenn du jetzt zum Beispiel sagst, ne, das Internet wurde irgendwann.
Ja mal verbreitet und da wurden ja im Endeffekt ist ja n Zusammenschluss aus Rechnern und damit diese Rechner halt eben auch miteinander kommunizieren können, gibt es also da wurden also sage ich jetzt mal, ursprünglich kam da so ein bisschen das ganze, diese ganze API App plication Programming Interface Nummer dann auch so richtig auf, also jetzt nicht mit dem Internet, aber so richtig ins Rollen, also jetzt nicht mit dem Internet selber auch schon vorher, aber halt
wenn es darum ging Netzwerke zu bilden, wo halt.
Unterschiedliche Kommunikation zwischen verschiedenen Systemen Halt ausgetauscht wurde und so hat sich das dann im Endeffekt auch entwickelt und aber natürlich auch auf verschiedenen Arten. Also es ist ja nicht nur so, dass du sagst, okay, du hast jetzt eine bestimmte Art, der das des Austauschs von Informationen über eine solche Schnittstelle, sondern es gibt ja verschiedene Arten, also du kannst jetzt zum Beispiel sagen okay das was du beschrieben hast
mit der mit diesem Lieferando beispielsweise wo? Du sagst, ich möchte gerne von Position x etwas bestellen und dann wird an einen Service gesendet. OK welche? Restaurants sind dann im Umkreis x stehenden zur Verfügung. Das wird ja wahrscheinlich. So stell ich es mir jetzt momentan diesem Beispiel vor, über das Internet abgefragt, was ja beispielsweise dann Web Apis sind. Irgendwo ne, das wäre ZB jetzt eine. Eine Art von Schnittstellen.
Aber es gibt ja auch noch andere Arten von Schnittstellen. Also zum Beispiel bibliotheks Apis besser, ich meine. Ja, ja, ist ein gutes Beispiel. Also so Bibliotheken oder Frameworks sterben ja auch Schnittstellen bereit, um auf deren Funktionalität zugreifen zu können. Dass das also. Ich glaube, dass wenn man über apis redet, im allgemeinen Halt, wie du schon meintest, sehr oft nur an sogenannte Web Apis gedacht wird, um zum Beispiel von einem Server Daten abzufragen.
Aber es gibt natürlich genauso auch ap is, sag ich mal so auf Coding Ebene, dass du halt Bibliotheken einbindet oder Framework verwendest. Und ja deren Funktionalität auch verwendest. Oder da Daten raus haben möchtest, da gibt es auch. Es gibt ja auch betriebsystem, Apis wie jetzt Posex zum Beispiel bei Unix, um auf systemrelevante Dinge zugreifen. Zu können. Ja, cooles Beispiel. Datei Operation zum Beispiel.
Und dann nutzt du ja auch ne Schnittstelle und sagst bitte an dem und dem Pfad möchte ich jetzt bitte n Pfeil löschen oder so. Genau. Genau. Ja, also das ist. Am Ende ist das ja auch nichts anderes. Ja, also das ist auch ganz cool, dass du das noch mal sagst, weil ich glaube, dass gerade in der heutigen Zeit, wo sehr viel auch logischerweise im Internet gearbeitet wird, wo es sehr viele Web Applikationen gibt, ist es gut, auch mal noch mal sich ein bisschen darauf zu besinnen.
Wenn man von apis redet, dass es halt eben nicht nur Web apis sind, das finde ich sehr gut, dass das noch mal gesagt hast, weil ich glaube, wenn ich angesprochen werde über apis, denke ich auch sofort als Erstes erstmal Web Apis oder oder noch spezieller an Rest Apis. Es gibt ja auch noch zum Beispiel andere Web API Schnittstellen wie zum Beispiel Soap oder so, das sind ja, es gibt ja verschiedene Möglichkeiten und ich denke wahrscheinlich als erstes
erstmal an Rest Apis, aber das ist eine andere Geschichte und eine andere Story. Ja, aber das ist ja das, was ich meinte mit, dass das so richtig ins Rollen gekommen ist, weil genau deswegen denkt man immer daran, weil der Anwendungsfall. Einfach so groß ist oder es an. Also wenn man sich mit Softwareentwicklung beschäftigt, geht ja auch kein Weg dran vorbei an zum Beispiel Rest AP is oben einfach ja. Zum Beispiel mit Servern zu kommunizieren, Daten abzufragen.
Da gibt es ja 1000 Anwendungsfälle. Aber es ist doch, also meistens landet man ja immer dann an dem Punkt zu sagen, okay, ich muss jetzt eine Rest API verwenden.
Das geht ja schon los. Wenn du sagst, ich möchte wissen, du guckst nach, du möchtest gerne wissen, wie das Wetter wird, dann fragst du ja irgendwo auf einer Webseite nach, zum Beispiel bei Wetter, schlagt mich tot, sagt er und fragst an, wie wird das Wetter heute oder morgen, das heißt, du stellst ja diese Anfrage. Blöd gesagt mit ey. Wie wird denn das Wetter heute? Und dann kriegst du ja über eine Web API über n Restbefehl von dem Server zurück.
Die Antwort die dir sagt ja es wird zum Beispiel sonnig oder jetzt ist es gerade noch richtig schön, aber in 2 Stunden fängt es an zu regnen, das sind ja im Endeffekt die Daten, die du dann sozusagen zurückbekommst. So kann man sich das ja so eine Web App im Endeffekt vorstellen und bei den anderen apis ist es ja ähnlich, das heißt du fragst irgendwas an, du möchtest
irgendwie. In der Information haben und diese Information bekommst du dann zurück und das interessante dabei ist ja, oder man kriegt ja relativ schnell jetzt vielleicht raus, dass man sagt okay, was ist denn eine API, weil eine API ist ja dafür da, nicht nur um zu sagen okay du hast eine Schnittstelle, sondern du hast ein System und stellst oder gibst eine API frei um zu sagen es dürft diese API darf auch benutzt werden von anderen Systemen, das ist ja auch noch
mal vielleicht sehr interessant zu abzugrenzen. Weil du kannst natürlich sagen, ich habe vielleicht. Ein eine Funktionalität, aber vielleicht hast du einen Server der anderen nicht zur Verfügung stellen möchte. Wie das Wetter wird, auch wenn der Server theoretisch die Möglichkeit hätte, weißt du was ich meine, das heißt eine API ist immer dafür da oder wenn es eine API gibt für ein System für Web API eine Bibliotheksabi, dann sind das ja immer Punkte.
Die das System nach außen zur Verfügung stellt und auch sagt, Du darfst diese Daten bekommen. Das ist vielleicht noch mal zusätzlich ganz interessant zu erwähnen. Genau ist es im Prinzip deine öffentliche Schnittstelle, also sagen wir mal in Anführungszeichen öffentlich, da können wir später noch mal darauf eingehen, aber die Schnittstelle in dein inneres System herein und du sagst darüber, welche Daten du preisgibst, wie du schon meintest oder welche Funktionalitäten ausführbar sind
von dir selbst. Und du kapselst ja quasi deine interne Repräsentation. Mhm von der Außenwelt ab. Genau ja, also im Endeffekt ist ja um dieses Wetter Beispiel noch mal zu nehmen, ist dir ja egal woher das Wetter kommt, was für Modelle da laufen um das vorherzusagen, das ist ja egal. Du willst einfach nur wissen. Morgen 18:00 Uhr wie wird vor voraussichtlich das Wetter sein? Genau, und dann kriegst du halt ne Antwort, die dir das beantwortet und dir ist egal was
n Wettermodell dahinter ist. Wer das gesagt hat, ob das keine Ahnung aus dem Kaffeesatz gewesen. Aber weißt du also, das ist ja genau der.es ist spielt für dich keine Rolle wie es da intern aussieht, dahinter sozusagen. Das wär auch geil, du kriegst irgendwie super ne riesen mega Daten, du musst selber noch sozusagen diese wie sagt man voraussichtlich voraus diesen Forecast machen, so wie wird das
Wetter genau. Das genau, und das ist nämlich ein sehr guter Punkt, was nämlich AP is beinhalten, ist immer eine Definition und gewisse Regeln, damit quasi beide Seiten auch wissen, was zu erwarten ist. Also im Prinzip es ist definiert wie deine Anfrage aussieht, dass du zum Beispiel sagst, gib mir, also ich muss Ort Zeit oder? Zeitraum übergeben und Krieg als Antwort, dann eine Regenwahrscheinlichkeit und eine Durchschnittstemperatur oder was
auch immer. Aber das muss definiert sein, damit beide Seiten wissen und da haben wir wieder das Puzzle, das quasi beide Teile wirklich perfekt ineinander passen, damit halt keine Unklarheiten entstehen.
Das ist halt der wichtige Punkt und deswegen gibt es halt klar definierte Regeln oder Definitionen nicht oder, sondern und und halt auch Formate, die ich erwarten kann, da ganz typisch werden ja jetzt zum Beispiel Jason für das Jason Format oder XML, dass du sagst okay, ich kriege jetzt zum Beispiel einen gewissen Datensatz, sozusagen Objekte zurück und die sind, ich weiß wie die formatiert sind, um mir die Daten, die ich. Möchte da wieder rausziehen zu
können. Die einzelnen Bestandteile und das ist halt auch ein wichtiger Punkt, dass es eine klar definierte Schnittstelle ist, die keine keine Unklarheiten offen lässt. Gesagt. Ja, auf jeden Fall. Also ich, wenn ich das so zusammenfassen würde, würde ich sagen, es gibt so eine Art Anatomie, dass du im Endeffekt oder eine Art. Beschreibung was überhaupt, was du überhaupt bekommen kannst, also welche Daten kriegst du überhaupt oder welche Fragen
darfst du stellen? Also du könntest jetzt wahrscheinlich zum Beispiel einer Wetter Api kannst du zwar fragen wie das Wetter wird. Blöd gesagt, aber du kannst zum Beispiel nicht fragen, wie schnell dein Auto fährt. Also also das ist halt sozusagen die Art der Endpunkte oder der zur Verfügung gestellten möglichen Informationen, die du bekommst. Dann sozusagen request und Response. Ne, es ist fest definiert wie du meintest, was darf ich überhaupt Anfragen?
Ich darf zum Beispiel sagen oder was muss ich mitgeben, wie du meintest und ich fand das das Beispiel ganz gut zu sagen du kannst zwar fragen wie wird das Wetter, aber du musst natürlich sagen OK wann denn heute, morgen, übermorgen wo bist du gerade, bist du am Südpol oder in Afrika, also wo bist du gerade? Das hat ja durchaus Auswirkungen und dann kannst du auch wirklich.
Nach diesem Request der festen Regeln und einem festen Struktur folgt, kriegst du auch eine fest definierten Response, also eine fest definierte Antwort zurück, die dir sagt, Okay, du bekommst jetzt das und das. Wir sind natürlich jetzt auch wieder von der Beschreibung her wieder bei Web apis aktuell, aber das geht ja auch bei Frameworks.
Also wenn du zum Beispiel bei einem Framework fragst, in welchem Lifecycle befinde ich mich denn zum Beispiel gerade oder was auch immer, da kannst du ja auch sagt das Framework okay hier darfst du jetzt zum Beispiel diese Information. Zu haben aber ne andere nicht. Und wenn du diese Information haben möchtest, dann ist es wichtig, dass du mir 23
Parameter als Anfrage übergibst. Und dann gebe ich dir diesen fest, definierten diese fest definierte Antwort zurück und wie du meintest, der dritte Punkt ist im Endeffekt neben Anatomie und diesem Request und Response ist ja die Doku, weil wenn du nicht weißt was du übergeben musst, dann kannst du ja diese API auch gar nicht ansprechen. Genau oder auch nicht weiß, was du empfängst. Dann kannst du es ja auch nicht verarbeiten.
Wenn du jetzt zum Beispiel denkst, bei dem Wetter, das ist ja eine ganz schön hohe Durchschnittstemperatur morgen um 18:00 Uhr dabei war das die Regenwahrscheinlichkeit von 80% oder so, weißt du ja oder Fahrenheit statt Celsius genau oder die Einheit, sowas spielt halt eine Riesenrolle, dann am Ende ganz genau. Wir verbrennen ja alle. Also deswegen gehe ich nicht raus. Fabian, weil ich diese Daten immer falsch auswerte und ich sollte mal 80 grad draußen. Bleib lieber drin.
Ich bleib lieber drin. Aber ein wichtiger Punkt dabei ist, und der wird jedem auch sofort begegnen, ist immer das von Endpunkten gesprochen wird. Und ich finde, da sollten wir auch noch mal drauf eingehen. Also wir haben ja im Prinzip schon so indirekt erklärt, was ein Endpunkt ist. Aber magst du das vielleicht noch mal ein bisschen zusammenfassen oder konkretisieren? Ich weiß gar nicht, was du jetzt genau hören möchtest.
Also n Endpunkt ist ja, im Endeffekt folgt ja also ich versuch das jetzt erstmal auf auf, wenn wir gerade bei Web Apis sind, also Web Apis hat zum Beispiel bestimmte Endpunkte, wo zum Beispiel verschiedene Methoden möglich sind, zum Beispiel ein Get sagt dir, du kriegst davon etwas, das sind ja zum Beispiel bei sagen wir mal bei einer Bibliotheksfunktion ist es vielleicht so eine Art Geta Methode? Oder zum Beispiel eine Put Funktion.
Das ist beinahe Web API. Ist es dann zum Beispiel da übergibst du Daten und möchtest neue Daten ins System reinschreiben beziehungsweise Daten die existieren verändern. Es gibt noch einen Post. Das ist wenn du neue Daten wirklich reinbringen möchtest ins System, die noch gar nicht existieren um das vielleicht falls jetzt irgendjemand sich fragt okay ich habe das schon mal gehört, Post und Put. Ist im Endeffekt, da sind wir jetzt bei den.
Http genau, aber Fakt ist ist, dass es im Endeffekt, wenn du es jetzt zum Beispiel wieder auf einer bibliotheks API funktionsmäßig siehst, ist es ein Setup, sagen wir mal und das heißt, du kannst entweder Daten abfragen auf einem Endpunkt oder Daten ins System bringen auf einem Endpunkt beispielsweise, und du übergibst halt immer eine bestimmte, sag ich mal ein.
Eine Möglichkeit also, ein, ein, ein Set an Daten, also entweder Parametern für die Anfrage, was möchte ich haben oder du übergibst Daten die du ins System reinbringen möchtest. So, und das ist wie gesagt Fest definiert, das sind für mich jetzt erstmal so Endpunkte in dem Sinne, aber vielleicht habe ich auch weiß ich auch nicht worauf du hinaus willst.
Gerade nein, das ist ja, das ist es ja am Ende auch, also im Prinzip. Endpunkte kann halt definiert werden und da kommt die Dokumentation auch wieder rein welche also ich habe eine gewisse Vorstellung was für Daten ich brauche und es muss dafür sozusagen ein Endpunkt geben, der mir diese Daten bereitstellt, klar definiert zum Beispiel, ich möchte jetzt eigentlich wissen, morgen um 18:00 Uhr, was für ein Wetter vorhergesagt wird und dann
müsste es dafür sozusagen, wenn das alles sauber ist, einen Endpunkt geben, wo ich quasi dann. Ort Zeit übergeben kann. Und ich kriege eine Prediction des Wetters zurück. Und ja wie der heißt, es ist ja, wenn wir jetzt wieder zum Beispiel bei Web API sind, wird es ja eine URL sein. Mit einem gewissen Pfad und zum Beispiel dann Slash Predict hinten dran und ich kann noch
Parameter übergeben. Jetzt mal nur rein genau als Beispiel ne oder bei einer bibliotheks API, dass ich ne Funktion predict aufrufen kann, wo mir die Dokumentation sagt jetzt gibt es bitte noch ein Date rüber, wann zu welchem Zeitpunkt diese Vorhersage getroffen werden soll und wo. So also so kann man sich das vorstellen.
Und dann ist das so gesehen auch ein Endpunkt, den ich ansprechen kann, mit definierten Vorgaben. Und ich kriege eine definierte, ein definiertes Format als Ergebnis wieder, und vielmehr steckt hinter dem Wort Endpunkt so gesehen auch nicht, es ist quasi, ja, es ist sozusagen meine Anlaufstelle, wo ich Sachen abfragen kann. Ja, ok, ich glaube, ich glaube, jetzt macht es bei mir auch so ein bisschen Klick.
Worauf du hinaus wolltest? Weil im Endeffekt kann ein Endpunkt ja auch einfach nur eine Funktion sein, die du aufrufst. Genau.
Und klar, es gibt ja jetzt gute und schlechte APIS, das heißt, es gibt vielleicht auch welche, die haben einen Endpunkt und da kann ich 1000 Daten reinkippen und Krieg halt unter irgendwelchen Voraussetzungen und Cases denn Daten zurück und dann wird es halt kompliziert und deswegen redet man ja so von verschiedenen Endpunkten, wo ich halt also sehr gezielt Sachen abfragen kann, um sie auch einfach strukturiert zu halten und modular vor allem auch. Finde ich ganz gut.
Also als. Wenn du jetzt n Auto kaufen willst und du sagst du hast n zum Beispiel n Endpunkt wo du sagst ich möchte keine Ahnung. Ich möchte also wissen was ich bei diesem Händler zum Beispiel für PKWS kaufen kann, dann gibt es da vielleicht n eigenen Endpunkt für genauso wie für LKWS oder was auch immer oder Motorräder. Wenn du aber zum Beispiel, du könntest natürlich die API auch relativ schlecht designen, dass du beispielsweise sagst, ich
möchte alle. Fahrzeuge und dann hast du ein Fleck. Was sagt Motorräder True Autostreo oder was auch immer sowas ne also er ist extra ein bisschen blöd gesagt aber naja oder verkaufte nicht lieferbare also es war alles drin und dann musst du über Daten die du reinkippst so filtern, dass du irgendwie eigentlich an deine
eigentlichen Infos rankommst. Beispielsweise also anstatt einen Endpunkt, wo du alles reinkippst und 1000 Millionen Möglichkeiten hast, das sozusagen zu konfigurieren, ist es natürlich schon schöner zu sagen für.
Sprechende Datenanfragen oder neue Daten eintragen gibt es halt auch entsprechende Funktionen beziehungsweise Endpunkte dann an der Stelle ja. Das ist also, liebe Zuhörerin, liebe Zuhörer, falls das Thema APIS für dich noch neu ist und du gerade ja diese Folge hörst und das nächste Mal jemand sagt, gibt es einen Endpunkt dafür, dann weißt du genau, was er meint und worauf er hinaus. Möchte und die Person wird sagen, ja, es gibt genau einen Punkt. Gibt genau einen. Endpunkt.
Und dann weißt du das, was du willst. Dann weißt du, man sollte mal refectern. Sehr wahrscheinlich, oder? Oder der Service, den du verwenden willst. Vielleicht hast du ja keinen Einfluss, genau, aber also das ist auf jeden Fall ein guter Punkt und im Endeffekt sind Hape s. Ja auch wirklich wie du schon meintest, es ist ja essenziell heutzutage, man braucht sie eigentlich fast überall.
Wie wir schon gesagt haben, zum Beispiel auf Betriebssystemebene, dass zum Beispiel auch Anwendungen halt eben mit dem Betriebssystem beispielsweise arbeiten können. Dafür wird halt eben von dem Betriebssystem.
Ne Betriebssystem API zur Verfügung gestellt, wenn wir zum Beispiel mit Framework arbeiten, wie zum Beispiel Springboot oder wir hatten letztens mal gudo ausprobiert, wenn man mit solchen Frameworks arbeitet, dann bieten diese Frameworks natürlich auch die Möglichkeit irgendwie, dass man mit der Anwendung auch, also mit diesem Anwendungen in Anführungsstrichen, also diesem Framework und seinem eigenen Code, den man schreibt, auch interagieren kann, aber genauso
ist es natürlich auch auf Web Ebene, wenn du zum Beispiel sagst, in verschiedenen Branchen, wie zum Beispiel dem Finanzsektor. Da ist es ja zum Beispiel auch so, dass du einer Bank vielleicht ermöglichst, mit verschiedenen zahlungsdienstleistungen Dienstleistern sich zu verbinden oder Zahlungsdiensten sich zu
verbinden. Ne, also dass du zum Beispiel sagst, ja gut, du kannst meinetwegen über Visa bezahlen, du kannst aber auch zum Beispiel über Mastercard bezahlen oder was auch immer, es gibt ja verschiedene Möglichkeiten oder Paypal zum Beispiel oder Paypal. Was auch immer, also es gibt ja genau das ist eine Menge klassischer Beispiel, was, glaube ich, klassisches Beispiel, was jeder kennt. Aber zum Beispiel auch bei dem Gesundheitswesen.
Wenn du sagst, du hast Patientendaten und du hast zum Beispiel ein Krankenhaus und wirst in ein anderes Krankenhaus überführt und musst diese Patientendaten weitergeben, oder die können abgerufen werden von einem Krankenhaus zum anderen oder von einem Arzt zum anderen, dann sind das ja auch irgendwo einzelne Systeme, die aber versuchen, irgendwie miteinander zu interagieren und zu sagen, könnte ich bitte Patient a oder von Patientin B die Daten haben, könnte ich die bitte kriegen und
dann bekommst du die. Und dann musst du die natürlich aber auch irgendwie wissen, okay was kriege ich da eigentlich und wie kann ich das bei mir eintragen beispielsweise? Und da gibt es ja viele Sachen. Ja, das sind auch sehr gute Beispiele. Wenn wir jetzt zum Beispiel noch mal unser wir bestellen Essen, Beispiel nehmen.
Wo wir gesagt haben, ja OK, dann gibt es halt eine Anwendung oder ein Teil deines Systems, was sich um die Bezahlung kümmert und dann hast du jetzt Dienstleister, wie du sie genannt hast und möchtest darüber die Bezahlung abwickeln, dann hast du ja im Prinzip wieder eine API aus deinem System zu einem Drittanbieter heraus, wo du die Bezahlung denn abwickelst und dann quasi die Antwort bekommst.
Jetzt mal ganz vereinfacht gesagt, Hey es bezahlt, kannst du. Als ja kannst du als bezahlt betrachten und weitermachen sozusagen. Und da sehen wir ja auch wieder, dass diese Schnittstelle, diese ganzen Systeme zu einem Gesamtservice verbindet, am Ende für den Anwender, das ist halt eine sehr coole Sache. Dabei, ohne dass der Anwender eigentlich sich großartig darum kümmern muss. Und das ist ja auch wieder das Schöne auf Anwendungsebene. Also es passiert irgendwo.
Ja genau. Oder ein anderes Riesenbeispiel, was auch jeder kennen sollte, ist natürlich sämtliche Loginprozesse, also authentifizierungs. Services ich mein, du kannst dich ja heutzutage so, also angenommen du hast n Google Konto, dann kannst du dich ja gefühlt bei jedem Service der mittlerweile aktuell ist sag ich mal mit deinem Google Konto anmelden. Du musst dich nicht überall wieder registrieren, sondern. Es wird quasi ein Service von Google genutzt, der dich
authentifiziert. Ja, doch hier kann man so sagen, genau und dann quasi zurückgemeldet wird ja OK, es ist User XY, du kannst jetzt mit seinen Benutzerdaten sozusagen weitermachen. Auch ein schönes Beispiel. Und das ist nämlich genau der Grund, warum AP is am Ende.
So sinnvoll und mächtig sind, weil da können wir ja jetzt langsam mal drauf eingehen, weil das ist wirklich ein spannender Punkt. Warum macht man das und welche vor und Nachteile hat das bzw sagen wir mal die Vorteile und Nachteile, wenn es halt schlecht designte Apps sind. Aber das ist halt ein riesen Punkt, diese Wiederverwendbarkeit. Es gibt jetzt beispielsweise
diesen Bezahlservice, oder? Authentifizierungsservice und den kann ich ja. Also jetzt sage ich hier, du kannst mir Daten geben und ich authentifiziere diesen User und dieser Service kann jetzt von sämtlichen Anwendungen. Verwendet werden, sei es von der Essens App, sei es von keine Ahnung, irgendein Spiel oder also überall wo so Loginstant verwendet werden. Und das ist ja ne mega coole Sache diese Wiederverwendbarkeit auch dahinter ne.
Ja, das ist ja im Endeffekt so n bisschen wie ich mag das immer, wenn man so miteinander redet, da hast du ja auch irgendwie ne gewisse Regelbasis, auf der du arbeitest, und zwar die Sprache, die zugrunde liegt, also sei es jetzt zum Beispiel Englisch, französisch, italienisch, deutsch, frag mich nicht, das heißt, du hast ne gewisse Syntax mehr oder weniger und das Verständnis darüber, wie das zu interpretieren ist, ist auch wichtig und wenn du das aber kennst und weißt, wie das
funktioniert, dann. Kannst du miteinander kommunizieren, dann ist es ja auch egal, ob du zum Beispiel, ob ich jetzt mit dir kommuniziere oder ob ich jetzt zum Beispiel weiß ich mit Person xy oder meiner Mutter
kommuniziere. Das ist ja völlig egal, weil solange alle die gleiche Sprache sprechen, also das gleiche Interface bedienen, mal blöd gesagt, hast du am Ende die Möglichkeit, dich miteinander auszutauschen, du musst nicht mit jeder Person, sage ich jetzt mal einzeln sprechen, ja, also gut klar, Personen an sich haben Emotionen und so weiter du weißt, dass. Computer nicht. Nein, aber du weißt ne, du weißt was ich meine und das ist das find ich, das kann man immer ganz gut so.
Mal als Analogie nehmen, mal wieder ne, um zu verdeutlichen was eigentlich. Der der Knackpunkt.
Ist, wieso man solche apis überhaupt erfunden hat oder auch nutzt heutzutage ne ja ist ne tolle Sache, so n. Klassisches Beispiel was man super in die API Welt packen kann wenn du ich find das kennen doch viele ne also man war so n kleiner Junge oder n kleines Mädchen also ein Kind noch ne und hat zum Beispiel einen Elternteil gefragt ob man etwas darf so und du wusstest du bist ja man geht ja gezielt schon zu dem Elternteil wo man weiß da ist mehr erlaubt also da ist die
Wahrscheinlichkeit höher man ist ja nicht. Als Kind. Und dann kommt immer dieser berühmte Satz, zum Beispiel, ja, da, da musst du deinen Papa fragen, mal als Beispiel, wenn jetzt die die Mutti quasi mehr zulassen würde und diese Person, also deine Mutti schickt dich aber zu deinem Papa. Für sozusagen die Authentifizierung oder die Autorisierung, in dem Fall, das heißt, es ist im Endeffekt auch wieder ne API.
Geh mal mit deiner Anfrage oder Sie verrückst versichert sich erstmal bei Papa und frag diesen Service an und der sagt Nee abgelehnt. Und dann hast du im Prinzip nämlich einen wichtigen Punkt, auch bei APIS. Was die Ermöglichkeiten ist, nämlich der Aspekt Sicherheit, darf ich überhaupt gewisse Sachen oder auf gewisse Daten zugreifen und dann gibt es halt Instanzen wie zum Beispiel beim Beispiel der Papa, der sagt. Du nicht. Und das sowas kann ja auch wiederverwendet werden.
Du kannst ja mit sämtlichen Anfragen immer wieder zu Papa gehen und sagen und wie sieht es heute aus? Und das ist halt auch n Punkt, dass du halt sag ich mal, Sicherheitsaspekte sehr gut damit umsetzen kannst. Ja, und das ist das, was ich vorhin meinte. Es ist zwar öffentlich und deswegen hatte ich vorhin gesagt, in Anführungszeichen. Weil ja auch beispielsweise gewisse Authentifizierung stattfinden muss.
Dass du zum Beispiel dich ausweisen musst während dieser Anfrage und dann nur Daten kriegst, wenn dieser, wenn du quasi autorisiert bist, dazu. Genau die zu bekommen und damit, das lässt sich halt wunderbar damit umsetzen. Ja, es gibt ja zum Beispiel auch öffentliche apis, ne, also jetzt wieder Web Apis, wo man auch einfach so Daten sich holen kann
oder ab snacken kann. Mal blöd gesagt, aber manchmal gibt es ja auch öffentliche apis, die sagen okay jeder darf das rein theoretisch, aber du brauchst trotzdem einen bestimmten Schlüssel dafür, damit du das machen darfst. Das heißt, das ist klar dokumentiert, was passiert nach außen hin, aber es steht dann halt auch da. Du musst beispielsweise ein Token mit übergeben, dass du überhaupt ja quasi. Autorisiert bist, das zu bekommen, also damit man dich auch identifizieren kann,
sozusagen. Ja genau richtig, das ist halt auch noch ein wichtiger Punkt dabei. Genau, aber das ist ja jetzt sozusagen der Punkt, wo man sagt, okay, wir wollen eine API verwenden oder nutzen, eines kann ja auch durchaus mal sein, dass man sich jetzt vielleicht sagt, Ey, kann man denn apis auch selber irgendwie?
Erstellen und natürlich kann man das ne, also man kann sich jetzt hinstellen und sagen, OK, ich möchte jetzt zum Beispiel ein eine Web API selber aufsetzen, dass man selber zum Beispiel sagt, OK, ich möchte jetzt Daten anbieten, die ich zum Beispiel selber mir errechnet habe, was auch immer, denkt euch irgendwas aus, es ist ja möglich, also so eine API zur Verfügung zu stellen oder halt auch einfach nur zu Testzwecken mal zu basteln, genauso wie zum Beispiel Library zu erstellen
die von anderen. Programmcode Stücken genutzt werden darf oder dürfen, wie zum Beispiel auch ich schmeiße jetzt einfach mal npm eine npm Library ins Rennen hier, das ist ja im Endeffekt kannst du eine Art Library erstellen mit einer Art API, die dir sagt okay, ich möchte jetzt aus diesem ja aus dieser Lip einfach mal Daten nutzen, also wie zum Beispiel irgendwelche mathematischen Berechnungen.
Wenn du jetzt sagst zum Beispiel, ich möchte jetzt gibt es. Ja, bei vielen Programmiersprachen. Wo du einfach bestimmte Libraries nutzen kannst und du weißt aber eigentlich gar nicht, OK, wie wird das jetzt zum Beispiel verwendet, was was wird da berechnet und so weiter aber. Wenn man das jetzt selber mal
machen möchte. Da kommt man ja vielleicht in die Versuchung. Also ich hab zum Beispiel auch irgendwann mal angefangen ne Web API zu schreiben und dachte mir, OK, wie mache ich das eigentlich ne und. Hast du vielleicht irgendwie so n paar Tipps einfach mal wo man sagt da darauf sollte man vielleicht schon achten, wenn man damit anfangen möchte oder ist eigentlich egal. Na ja, was heißt egal. Also es klingt immer so n bisschen trivial, aber der erste Typ ist natürlich Anfang und ist
nicht zu überdenken. Am Anfang würd ich sagen, weil apis zu refacto ist jetzt auch nicht unüblich, es kommt halt gut, kommt auf den Anwendungsfall an. Wenn du jetzt viele Systeme hast oder Anwendungen die deine API verwenden hast du gewisse. Challenges. Ich würde es nicht Probleme nennen, aber Challenges. Du musst halt sicherstellen, wenn du Sachen änderst.
Das ist beispielsweise abwärtskompatibel ist, dass du halt nicht sogenannte Breaking Changes erzeugt, das ist aber ein Thema, das können wir später behandeln. Trotzdem würde ich sagen erstmal anfangen und dann versuchen, so keep it simple mäßig um einfach eine gewisse, also um es intuitiv zu halten, dass du dann zum Beispiel den Endpunkt definierst, wie beispielsweise mit dem Wetter, der. Erstmal an sich simpel und klar definiert. Also er ist einfach verständlich.
Du selbst anhand nehmen wir jetzt zum Beispiel Web API an der Adresse schon sehen kannst oder erahnen kannst, worum es sich handelt und dann das ganze klar dokumentierst, dass du zum Beispiel sagst, Hey, pass auf, gib mir Ort und Zeit und ich gebe dir. Folgende Wetterdaten so und dann weiß ja jeder, wie das zu verwenden ist.
Ja, also. Ich also wichtig ist, dass es intuitiv ist in meinen Augen, dass man nicht ewig als Anwender rumrätselt ist das jetzt der richtige Endpunkt oder was will er jetzt für Daten haben und was kriege ich eigentlich zurück? Das ist nämlich dann die richtige Anwenderhölle am Ende und die gilt es zu verhindern. Aber das finde ich, ist auch immer sehr spannend, weil du weißt ja, wie das manchmal ist.
Du fängst an, so etwas zu entwickeln und kommst dann irgendwann an einen Punkt, wo du selber den Wald vor lauter Bäumen. Das heißt, du weißt ja selber ganz genau, wie du ne diese diese API bedienen müsstest und checkst vielleicht gar nicht mehr das andere, das nicht wissen könnten. Weißt du, dass du so in der
Materie drin steckst? Das sagst du ja, ist doch logisch, wenn du das brauchst, dann machst du das so aber also da muss man glaube ich vielleicht, also ich sag mal so, ich habe auch damals irgendwann angefangen eine API zu entwickeln, mal so aus Spaß ein bisschen oder halt auch so ein bisschen mehr ernst als Spaß im Sinne von ich wollte einfach mal was ausprobieren und wirklich für eine.
Anwendung mal einfach das ganze Mal machen und dann kommst du irgendwann auch an nen Punkt, wo du dir dann vielleicht denkst oder zumindest war es bei mir so, dass ich mir dachte, so hm warte mal. Warum ist zum Beispiel, warum gibt es zum Beispiel n Putt, warum gibt es n Post? Ich hab zum Beispiel am Anfang alles über Baguettes gemacht und ich finde das ist prinzipiell überhaupt nicht schlimm, weil du lernst ja so, das heißt du kannst ja nur lernen, indem du
das Ganze machst. Das heißt die erste API wird sehr wahrscheinlich nicht perfekt sein, so war was heißt perfekt, aber. Die Sache zu sagen, klar kann dir jetzt irgendjemand sagen, ja, mach jetzt nicht für alles, nimm nicht für alles den gettend Punkt oder diese Methode das. Mag total sinnvoll sein, aber am Ende kann man ja trotzdem sich
das ganze auch selber mal. Ausprobieren, weil irgendwann kommst du. Ein Punkt, wo du dir sagst, ich möchte jetzt zum Beispiel Daten übergeben, das geht mit einem Get Endpunkt gar nicht so gut, das heißt ich möchte neue Daten in das System schreiben und das funktioniert darüber gar nicht, spätestens wenn du irgendwann an den Punkt kommst wo du sagst ich möchte beispielsweise angenommen stell dir mal vor, du hast irgendwie möchtest dir ein kleines Profil bauen und
möchtest dieses User Profil, dem möchtest du ein Bild hinzufügen und dann denkst du dir so ich hab jetzt immer get benutzt obwohl jetzt muss ich ja aber eigentlich Daten ins System geben und. Ich kann aber keinen Bild ins System. Von außen geben und sagen, ich möchte mein Bild ändern, ne mein profilbild über n gat Endpunkt, das funktioniert halt nicht und demzufolge kommst du dann irgendwann an den Punkt wo du sagst ach so warte mal. Dafür gibt es zum Beispiel n Post oder n Put ne nicht.
Auch zum Beispiel meinte Wenn du nimmst zum Beispiel n Post wenn du neue Daten ins System schreiben möchtest die noch nicht da sind, neue Datensätze und Put nimmst du eigentlich eher dafür wenn du sagst der Datensatz ist schon da, aber ich
möchte Daten verändern. Aber das sind, das ist ein Lernprozess und ich finde es immer, was ich schwierig finde, ist, dass wahrscheinlich, denkt man sich am Anfang, ey, ich muss es richtig machen, und wenn irgendjemand kommt und es sieht, sagt er, warum machst du das so, das ist voll blöd, aber das ist, finde ich, immer voll schwierig, weil eigentlich, man muss halt einfach diesen Prozess auch manchmal gehen, klar kann man sich Best Practices nehmen, sich einlesen, das ist natürlich
wichtig, genauso wie zum Beispiel, wenn du von Endpunkten geredet hast, dass du dann auch wirklich eine bezeichnenden End.
Ist also in der URL zum Beispiel Predict oder so und nicht keine Ahnung, halli Hallo hallöchen, aber das ist alles n Lernprozess und ich glaube man kann sich ne Menge anlesen und auch ne Menge von irgendwie wissen von wem anders mitnehmen und vielleicht auch auf Ratschläge hören aber das wichtigste und da gehe ich total bei dir mit ist einfach erst mal anfangen und mal
ausprobieren und mal gucken. Und das ist gerade am Anfang, dass ich finde aber auch gut, dass du sagst, Pass auf Abwärtskompatibilität, das ist ja dann schon bisschen auf fortgeschrittenem Niveau, dass du sagst, was passiert denn, wenn 5 Systeme deine API nutzen und du schmeißt jetzt auf einmal ein Parameter raus, der aber vorher wirklich zwingend notwendig war und jede Anfrage die daran kommt, fliegt mit dem Error ab, weil ja quasi die Definition zwischen erwarte ich
von einer Anfrage nicht mehr übereinstimmend mit, dass ist meine Anfrage. Ja, oder ein Endpunkt wird umbenannt beispielsweise. Noch einfach ein. Beispiel ja, also das ist so n Klassiker, dass du denn denkst, ja nee, so intuitiv wisst ihr nicht, der Endpunkt, ich muss den Mal umbenennen und vergisst halt in dem Moment, dass ja viele Systeme darauf setzen und diesen Endpunkt abfragen beispielsweise ja. Und dann funktioniert er halt nicht mehr und die wundern sich so.
Hä, was ist denn jetzt los? Mein ganzes System steht still, quasi ne ja. Genau, also lange Rede, kurzer Sinn eigentlich, was ich eigentlich sagen wollte ist, ich möchte mal. Ich möchte eigentlich immer.
Leute, fass es noch mal. Zusammen ich möchte, ich möchte eigentlich nur Leute dazu animieren, dass man einfach mal anfängt, weil es gibt so oft, dass man dann einfach sagt, so, ja, wie mache ich dies, wie mache ich das, ich brauche Best Practice blubby Blue einfach mal machen und dann entwickelt sich das ganze und dann kann man daraus lernen, also besser als.
Ich würde es gerade einfach nur witzig, dass ich so sage, ja einfach mal anfangen, das ist erstmal das wichtigste und du das ist aber richtig schön ausführst und am Ende das Gleiche zu sagen. Ja, ich weiß, ich weiß, aber ja, es ist. Manchmal so wichtig.
Ja, es ist auch wichtig, und das muss man auch ganz klar aufzeigen, weil man kennt das ja von sich selbst, dass man sagt, ach nee, aber erstmal muss ich wissen, wie es ganz genau geht und Best practice hier und best Practice, da bin ich ja auch ganz bei dir und das ist auch ein sehr wichtiger Punkt. Ich ertapp mich dabei immer noch heutzutage bei sowas. Ja, natürlich. Man man schiebt quasi dieses anfangs halt immer mehr nach hinten.
Wenn man sagt, ja, nee, erstmal muss ich noch wissen, wie das und das. Funktioniert. Absoluter Klassiker in sämtlichen Bereichen. Ein Punkt, auf den man aber wirklich meiner Meinung nach frühzeitig achten sollte und den vielleicht nicht vernachlässigen sollte, weil der ist. Nicht schwierig in der Definition, sage ich mal. Aber schwierig ist, konsequent umzusetzen, wo jetzt vielleicht wieder Leute sagen werden so.
Hä also jetzt mal ganz ehrlich, das ist doch sowas von selbstverständlich, aber man hat schon viele APIS gesehen, wo es nicht so selbstverständlich ist und das ist die Fehlerbehandlung. Dass deine Endpunkte auch Fehler behandelt sind und der Anwender quasi auch erfährt, wenn was schiefläuft und vor allem was schief läuft, ist auch wichtig. Wenn wir zum Beispiel wieder bei Web AP IS über http sind. Du kannst nicht immer mit 200 ok antworten und sagen.
Sage ich mal quasi per Statuscode sagen, ja, völlig in Ordnung, was hier passiert ist. Aber eigentlich ist irgendein interner Fehler aufgetreten, weil Daten nicht gepasst haben oder vielleicht Parameter gefehlt haben und da muss halt dementsprechend auch eine Fehlerbehandlung stattfinden, dass der Anwender informiert wird, was denn schief gelaufen ist. Und das klingt halt trivial oder so selbstverständlich, aber hat man auch schon anders erlebt,
das. Hatten wir auch im Interview mit Anthony, der uns auch noch mal auch aus seiner Sicht mitgebracht. Hat, dass es ja auch durchaus ein häufiger Punkt ist in realen Systemen. Ja, und das ist halt schon interessant, auch einfach wenn du sagst, OK, ich möchte zum Beispiel eine Anfrage stellen, du bist unautorisiert und darfst es aber gar nicht und das. Der Endpunkt gibt dir aber zurück. Alles super. Super.
Alles super und und n anderes Beispiel ist auch dahingehend die Dokumentation, dass das natürlich auch dokumentiert ist, was für Fehler auftreten können und wann sie auftreten und n wichtiger Punkt, was wir auch erst vor Kurzem erlebt hatten, als wir so Third Party quasi einen Dienst verwendet haben ist, dass die Doku geupdatet wurde, so nach dem Motto über diesen Endpunkt gibt es jetzt andere Daten.
Beziehungsweise das System benötigt andere Daten und über den Endpunkt XY könnt ihr diese Daten erhalten.
Wenn ihr euch sag ich mal autorisiert habt, so das haben wir gemacht, dachten uns ja gut, das machen wir vorher auch schon gemacht, der Witz war nur dabei, dass dieses neue Format was das System erwartet und angeblich über einen Endpunkt bereitstellt, nicht geupdatet war, das heißt, die Doku wurde geupdatet, alle Systeme wurden geupdatet und dieser eine Endpunkt war veraltet, da fragt man sich auch.
Wie kann sowas passieren? Oder am Ende mussten wir n kleines Skript schreiben, was diese Daten noch mal quasi ja konvertiert hat und das das war ja für uns auch n Tag Arbeit weggefühlt und das sind halt so Sachen, die dürfen nicht passieren wenn man so n Betreiber einer API ist. Meiner Meinung nach definitiv, aber Fakt ist sowas passiert no Problem aber das sollte man halt immer im Hinterkopf haben.
Ja, es ist auch immer es ist. Es ist einfach so ne API zu konsumieren und Daten davon abzufragen und dann zu merken, da funktioniert was nicht und auch auf der anderen Seite zu sein und mal zu sagen Okay warte mal ein riesenunterricht ich muss eine API zur Verfügung stellen und was passiert denn aber also oft erst mal. Also ich sag mal das erste Mal auf die Idee zu kommen aber vielleicht auch das zweite Mal weil es dann doch mal irgendwann wieder passiert zu sagen okay.
Wir haben jetzt hier was geändert. Ah Moment, das sind ja nicht nur wir, die das machen und benutzen und so weiter also ich hatte zum Beispiel mal den Fall, dass wir n System hatten aus sag ich jetzt mal, also n Gesamtsystem aus 2. Teilsystem und diese Teilsysteme haben miteinander gesprochen und dann haben wir fröhlich vor uns hin programmiert und haben gesagt, ja, lass uns mal das den Datenaustausch verändern, weil das ist doch einfach viel
effizienter und viel besser. Oh ja, das ist ne super Idee und dann haben wir das gemacht und ja so ne halbe Stunde später kam dann irgendjemand zu uns an und meinte Leute irgendwie funktioniert bei euch was nicht mehr und wir so oh nein, wir haben ja diese API die wir da auf der einen Seite verwendet haben, die verwenden ja auch noch andere.
Das ist uns da mal dann in dem Moment auch erst aufgefallen, dachten so, Oh Gott, Oh Gott, oh Gott, oh Gott, ja stimmt, und das ist dann halt wegen sowas passiert, das ist dann halt auch wieder die Möglichkeit zu sagen okay, wie geht man damit um? Also es gibt auch Möglichkeiten, Stichpunkte, zum Beispiel Versioning der API und und und. Ist aber ein weiterführendes Thema und da sollten wir heute jetzt nicht mehr darauf
eingehen, glaube ich. Ja, deswegen ich würde sagen, wir haben das auch ausführlich besprochen. Ich, ich kann es ja noch mal so ein bisschen. Zusammenfassen, was wichtig denn bei also nicht noch mal was eine API ist, sondern was jetzt quasi so. Gute Punkte sind, wenn man jetzt beispielsweise ne eigene API entwickeln möchte. Also ganz klar sind für mich halt ne, die Dokumentation ist entscheidend, damit jeder weiß
wie sie zu verwenden ist. Aber das gilt so für beide Seiten. Die Fehlerbehandlung, was wir gesagt hatten, ist halt wichtig, dass man da wirklich konsequent ist. Bei dem ganzen naming Konvention, die man verwendet, dass man da auch einfach einheitlich ist, dass man quasi n klares Muster hat, würd ich noch sagen, das hatten wir eben nur so n bisschen am Rande erwähnt, aber finde ich ist auch ein guter Punkt, der sich sage ich mal so Instant umsetzen lässt.
Wenn man das im Hinterkopf hat. Also da braucht man ja nicht sag ich mal viel wissen drüber, aber das sind halt Sachen, das ist einfach einheitlich ist, weil das fördert auch irgendwie nachher dieses Intuitive verwenden. Genau, was hatten wir noch. Die Vorteile könnten wir noch mal sagen Warum überhaupt AP is, könnte man noch mal zusammenfassen, da hatten wir ja gesagt, also es ist einerseits modular wiederverwendbar, was ein riesen Punkt ist.
Beispielsweise hatten wir den Bezahlservice genannt, der jetzt von sämtlichen Systemen, die irgendwelche Bezahlvorgänge beinhalten, von denen verwendet werden kann, ohne dass jeder jetzt seinen eigenen Bezahldienst quasi implementieren muss, dass wir halt so ein riesen Punkt dabei. Das ganze skaliert halt dadurch super.
Ne, also du kannst beispielsweise auch ohne Probleme deine Systeme erweitern, ist vielleicht noch so n Punkt, den hatten wir ja noch nicht so richtig herauskristallisiert, was daran geil ist. Du kannst ja Endpunkte. Sag ich mal über die Zeit hinzufügen und damit mehr Funktionalität in deinen Service reinbringen und gezielt nach außen gehen und das halt auch noch n supergeiler Punkt und halt auch Sicherheitsaspekte wie die Analogie mit dem Papa Fragen.
Das lässt sich damit halt auch super umsetzen. Die hat mir auch sehr gut gefallen. Und natürlich, liebe Zuhörerin, lieber Zürcher, wenn du anfangen möchtest ne API mal zu schreiben, mach das was Tino gesagt hat und was ich nachgeplappert habe. Ich wollt es ja nur noch mal unterstreichen, Tino einfach mal anfangen, ja. Nicht so viel drüber gedacht, genau nicht verkomplizieren das Ganze genau.
Ja dann würde ich sagen, haben wir das doch sehr ausführlich besprochen und eine gute Einleitung gegeben und ich hoffe die Fragen die auf uns herangetragen wurden.
Wird auch beantwortet worden. Vielen dank Fabis hat mir mega Spaß gemacht, wieder war ne coole Folge, ist ja immer cool wenn man danke danke wenn man so über grundlegende Themen einfach noch mal spricht und sich das vor Augen führt was eigentlich dahinter steckt, warum weshalb das finde ich halt immer super spannend, weil ich glaube man kommt irgendwann in seiner Software entwicklungskarriere an den Punkt wo jemand sagt API und wie du schon meintest, dass man denn je nach Branche wo man
arbeitet sofort immer ein Bild von irgendwas im Kopf hat. Und dann sofort in seiner Welt ist ne, ist halt auch spannend das noch mal ganz ja aus der Vogelperspektive sozusagen zu betrachten und mal ganz grundlegend, deswegen hat mir wirklich viel Spaß gemacht. Vielen Dank. Und Liebe zuhören, liebe Zuhörer, ich hoffe oder wir hoffen, dir hat die Folge auch gefallen und du hattest Spaß dabei und vielleicht noch die ein oder andere Info rausgezogen, die dich weiterbringt.
Falls ja, freut uns das natürlich sehr. Dann würdest du uns auch freuen, wenn du den Podcast weiterempfiehlst. Falls er dir gefällt, vielleicht so an 23 Freunde einer wär auch OK, 2 wären besser. Die links zu einem Plattform findest du wie immer in den Shownotes. Ansonsten, wenn du Feedback zu der Folge hast oder auch Anmerkungen zu dem API Thema,
Lass es uns gerne wissen. Unsere Podcast Mail findest du ebenfalls in den Shownotes und ansonsten würde ich sagen bis zum nächsten Mal wieder, wenn wir uns alle wieder hören und ja bis dahin eine schöne Zeit und bis zum nächsten Mal deine Coding Buddies. Gemeinsam besser.