Latest / Coding Buddies | Tech & Dev-Mindset / Was sind eigentlich APIs?

Transcript

Was sind eigentlich APIs? · Coding Buddies | Tech & Dev-Mindset

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