Moin zufolge 66 von einfach komplex wir sind.
Ich würde schon sagen zurück aus der Sommerpause, stimmt aber
nicht, weil wir haben durchgemacht und der anderen
Podcast kommen wir jetzt erst wieder.
Wir, das sind natürlich Burkhard und ich Burkhard.
Moin Moin hier aus Hamburg. Wir möchten heute sprechen über
die Rest API. Ich habe gerade noch mal
nachgeguckt, wir haben in Folge 16 schon mal über die Rest API
gesprochen, allerdings nur 56 Minuten, so als Randthema beim
gesamten Thema API, die Rest API ist aber so wichtig, dass wir
heute noch eine eigene Folge widmen wollen, der Plan.
Ist, dass wir uns erstmal so ein bisschen die Grundlagen
angucken. Besser gesagt von Burkhard
erklären lassen und dann gemeinsam in die Practices für
so eine Erstellung von oder von einem Design von der Rest API
uns ansehen. Und das ist dann aber der zweite
Schritt. Jetzt geht es erstmal um die
Grundlagen, ich fange mal an mit einer Erklärung was was heißt
eigentlich Rest API oder wofür steht das, ist die
Repräsentational State Transfer. Api steht für Application
Project. Surface und jetzt bin ich aber
auch durch und übergebe erst mal Dichbock hat, dass du uns mal
gruppenüberblick gibst. Was ist ne Rest API, wofür
benutze ich sie? Und ja was ist das Schöne daran
eigentlich? Ja, Rest APIAPI impliziert schon
Application Programming Interface.
Das heißt ja wir sind hier dabei nicht an Interface zu generieren
für den Menschen, für den Humanuser, sondern eher für ein
Programm und das ist was eine Rest API tut.
Es ist zur Entkopplung da. Also ich habe eine gewisse
Business Logik und sehr oft ist diese Business Logik irgendwie
so eine Quad Logik. Das Wort Quad kam uns schon
öfters mal in diesen Podcasts entgegen, steht für create read
Update Elite, das heißt ja innerhalb meiner Business Logik
spricht man typischerweise von Ressourcen.
Ich nehme gleich mal ein Beispiel in die Hand, zum
Beispiel einen Blogposter, da sind die Ressourcen zum Beispiel
die einzelnen Blogs und. Ich kann halt Blogs kreieren,
ich kann die updaten, ich kann die wieder löschen und ich kann
die lesen, da sind bin ich beim Quad dabei und wenn ich jetzt
zum Beispiel. Ein System haben möchte, eine
Business Logik haben möchte, die für User Blog Posts verwaltet,
dann kann ich mir schon bevor ich überhaupt das irgendwie
programmieren umsetze, kann ich mir schon überlegen, wie könnte
denn ne gute Rest API für so nen blogspot wo ich quasi user
verschiedene User erlaube verschiedene Blogs zu kreieren
und zu verwalten und so weiter wie könnte so eine API aussehen
und das leistet eine Rest API? Also ich kann ich kann so eine
gesamte Businesslogik. Da einer Blog Verwaltung in
einer Rest API Gießen und danach wenn ich das habe, dann können
quasi Programme Klienten wie man sie nennt mit dieser API quasi
die entsprechenden Business Logiken anstoßen und ich kann
dann entkoppeln. Ich kann dann sagen okay ich
habe zum Beispiel eine schöne Webseite, eine UI, mit der kann
ich dann quasi durch klicken von Knöpfen und einfüllen von von
html Text zum Beispiel kreiere ich quasi solche Blogs.
Ist aber völlig losgelöst von der eigentlichen Business Seite.
Der Rest API AG, die agiert immer gleich, egal wie es quasi
visualisiert wurde. Das ist die Grundidee.
Einer Rest API ja, und das also quasi eine, eine ein Interface,
was vor allen Dingen und ja auch dass sie noch mal sagen im Web
benutzt wird. Ja, denn derjenige der die
Businesslogik ausführt, das ist immer nen Webserver.
Webservice sagt es man auch. Ja nen Dienst.
Der mir erlaubt, quasi mit seiner Datenbank im Hintergrund,
in diesem Fall zum Beispiel Blogposts zu verwalten.
Ne schon n bisschen länger schwadroniert, aber ich glaub,
da haben wir jetzt erstmal so ne Übersicht.
Die Übersicht ist perfekt. Also ich hab verstanden es ist n
Backend Service. Abstrahiert hier quasi auch
gewisse Funktionalität? Ja, die ich dann einfach aus dem
Frontend oder aus verschiedenen Frontend auch aufrufen kann und
nutzen kann, wahrscheinlich auch Backend zu Backend nutzbar,
oder? Ja, das geht auch, ja.
Kein Problem, Es gibt noch andere apis oder Architekturen,
API Architekturen, die in dem Zuge Rest häufig mal genannt
werden. Das ist Soap, also wie die Seife
SOAP und Rough Qall. Würdest du noch mal ganz kurz
abgrenzen. Rest zu den.
Genau das sind also Soap ist vor allen Dingen bisschen, gibt
schon n bisschen länger, ist so historischer gewachsen, sag ich
mal. Aber vielleicht vor Rest da.
Soap. Also wir haben ja noch gar nicht
im die technischen Details gesprochen, aber also Rest ist
quasi. Ein sehr leichtgewichtiger Art
und Weise, wie ich definiere, wie diese API auszusehen hat.
Bei bei Soap ist es viel strenger reglementiert, ja auch
die Arten der Nachrichten und und die Art und Weise der der
Error Behandlung und so weiter das ist alles, ja das ist mehr
protokollartig sage ich mal ja, Rest nimmt sich da etwas zurück
in den Vorgaben, Soap ist deswegen auch eher war dann
früher auch eher gedacht für komplexere Transaktionen, so wie
im Banking Business usw. Ja, es ist ein richtiges
Framework und basiert auch auf XML und auch Autorisierung und
so weiter ist halt eingebaut und Soap, das nutzt nicht die
klassischen Webtokons und so weiter wie wir sie bei Resta
nutzen können. Also das ist quasi im Prinzip
Soap. Ja ich würde sagen, kommt kaum
nach vor heutzutage kann man mal gehört haben und kann man gleich
wieder vergessen, ein bisschen spannender ist Graph QL als als
weitere API. Graph QL ist ist anders als Rest
insofern. Dass du hier als Abfragender als
Nutzer der API schon sehr viel vorgeben kannst, wie du deine
Antwort strukturiert haben möchtest.
Also ich sage mal was der es gibt.
Der Service der im Hintergrund steht, der auch bei Rest APS im
Hintergrund steht, der sagt bei Graph QL einfach nur ich kann
dir das und das und das und das geben ja, aber in welcher Art
und Weise du das Abfragst und in welchem Nesting Level und so
weiter. Das bleibt dir überlassen,
lieber Klient. Ja, das heißt, ich muss als
Klient auch nen bisschen mehr hinschreiben um ne um ne Abfrage
zu formulieren und bekomme dann aber auch ne sehr spezielle
Antwort, ja. So funktioniert Graph QL und da
ist es bei Rest anders. Bei definiert der Server schon
ziemlich genau diese API. Ja, da gibt es halt genau die
Endpunkte, man spricht auch von den Endpunkten, kommen wir
nachher noch zu, die sind da und die kannst du nehmen oder pengen
ja und was anderes gibt es da halt auch nicht, ja.
Genau, und deswegen sagt man, dass das Graf QL manchmal, wenn
du setzt, ich sag mal, wenn du jetzt sehr komplexe Business
Probleme hast, reduziert es quasi so n bisschen das das das
zuviel Laden von Informationen ja weil zum Beispiel.
Für das, was du jetzt anzeigen willst, ja sind jetzt ist jetzt
quasi die Rest API Calls nicht super super drauf zugeschnitten.
Du musst quasi mehrere zusammen machen und dann die Daten
zusammenzuführen und so weiter das heißt so n bisschen Overhead
bei bei Rest. Wenn du bei Graph QL genau das
fragst, was du jetzt gerade brauchst, so die Idee, das ist
der Unterschied, ansonsten funktionieren die funktionieren
die relativ ähnlich sogar auch von der Technologie.
Verstanden? Ich glaube, das reicht vom
Detail Level was die Unterschiede angeht.
Wir haben eine wahnsinnige Latenz, müssen wir gucken, wie
wir das hier heute handeln, aber wir kriegen das schon.
Hin, ja, ich weiß auch nicht, es ist voll krass.
Dann lass uns doch mal in das Beispiel reingehen, was du
gerade gemacht hast. Ich habe jetzt verstanden, es
gibt einen Blog. Meinetwegen Unternehmensblog und
dort gibt es Artikel und die können von verschiedenen Usern
geschrieben werden oder halt dann Autoren letzten Endes und
auch verwaltet werden. Diese Artikel auf diesem einen
Company Blog als Beispiel und da wolltest du jetzt durchgehen und
für diesen Blog mal eine API, eine Rest API Design mit uns,
richtig. Versuchen wir mal, was da was
heißt, Design ne und versuchen wir auch mal n bisschen
durchzugehen, wie sieht das so aus und was brauchen wir
überhaupt für Komponenten und so weiter wir gehen mal n bisschen
durch und auch so n bisschen durch die Best practices wie man
es machen würde, ja. Also wenn wir jetzt mal bei
diesem Blog. Im Beispiel bleiben.
Dann müssen wir erstmal in der Rest API sogenannte Endpunkte
definieren. Ja, die Endpunkte sind
tatsächlich am Ende URLS im Browser.
Die verschiedene Namen haben und wir könnten zum Beispiel jetzt
bei uns haben nen Endpunkt, der heißt einfach Slash Users und
Slash Blogs ja. Unter slash Users könnt ich dann
zum Beispiel Informationen bekommen über die User, die halt
blogposts, also über die Autoren, quasi die die Blogposts
verfasst haben und so weiter und das Slash Blogs, da hab ich
erstmal gleich das Level auf auf die Blogs selber gesetzt und
könnte raus. Könnte mir zum Beispiel erst mal
alle Blogs anzeigen lassen, die da jetzt diese gerade Datenbank
kennt und so weiter und hier gibt es schon kleine Best
Practice, man macht es so, dass man.
Nomen benutzt ja. Also man würde den Endpunkt
Slash Users nennen und nicht get User oder Irgendsowas.
Also wir versuchen hier nicht funktionsaufrufe.
Oder Funktionsnamen, wenn die in die Endpunkte rein zu
definieren, sondern versuchen, diese Ressourcenansicht im Namen
widerspiegeln zu lassen. Ich hab halt die Ressource Users
oder user einen User, ich nehme dann immer den Plural und ich
hab die Ressource Blog, also gibt's Users und Blogs.
Wenn du jetzt Blogs sagst, meinst du nicht verschiedene
Blogs, sondern oder oder nicht verschiedene Seiten, sondern
Artikel quasi. Das ist für dich jetzt n Blog,
oder? Ja genau n Artikel mit mit ner
Überschrift irgendwie n Content und also title lass so n Blog
haben nen title, nen Content und n paar Tags oder irgendsowas das
ist n. Blog Tatsächlich hab ich immer
gedacht, dass n Blog, also quasi das ganze Ding ist und da drinne
gibt es Blog posts. Genau das gibt es auch, aber ich
würde es jetzt hier für das Beispiel, also das könnte man
jetzt auch noch weiter durcheinander kommen, ja richtig
genau, hast recht, wir machen jetzt mal einen, jetzt ist mal
so nen Blog einfach nur einen einen blogspot sag ich mal.
Ja der Blog und der Post, die verschmelzen jetzt in eine für
dieses Beispiel ja. Gut, dass du nochmal nachgefragt
hast. So und jetzt jetzt ist es so und
das muss ich vielleicht auch noch mal sagen.
Das ist nämlich auch n Unterschied zwischen Soap und
Graph QL. Es ist jetzt so, dass wir
tatsächlich diese verschiedenen Endpunkte haben, also wir haben
n Webserver. Und jetzt haben wir tatsächlich
schon mal Slash Users und Slash Blogs.
Das sind ja verschiedene ULS. Ja, das ist nicht so bei Soap
oder bei Gas QL, da gibt es quasi nur einen Endpunkt.
Ja, bei Gravqella heißt der Slash Graph QL ja und da hatte
ich ja gesagt, der Client gibt vor was für ne Anfrage los ist.
So, ja dann steht quasi in der in der Request vom Client steht
drin, gibt mir quasi die Users und der fragt aber Slash Gravql
und bei Assope ist es ähnlich. Nicht so bei Rest.
Ap is, da hast du quasi das Vordefiniert.
Ja, also die Ur Ls die du Anfragen kannst, die gibt's
Vordefiniert, das hat der Hapi Designer gemacht, so und und
jetzt kannst du ja quasi wenn du jetzt erstmal zum Beispiel
Ressourcen hast, dann kannst du ja, das hat mir vorher gesagt,
Agieren mit den Ressourcen und zwar entweder lesend und dann
benutzt du die http verben, die sind festgelegt vom http
protokoll, also das gad. Schreibt man immer groß alles
GET groß get das ist Lesender Zugriff.
Also wenn ich jetzt zum Beispiel get Blogs machen würde.
Dann wäre die die implizite Erwartungshaltung von einer gut
designten API, dass ich halt einfach alle Blogs bekomme, quer
über alle Users. Ja, get heißt lesen Ja.
So, und dann gibt es noch n Post Post heißt immer kreiere was
Neues. Ja leg an was neues, ne neue
Ressource, das heißt das immer und dann gibt es noch Put und
Patch die kommen immer als Pärchen das sind die Updates die
beiden Jungs also wenn ich und die werden wenn ich jetzt zum
Beispiel einen Blog nehme und will der schon existiert und
will zum Beispiel nur den Titel ändern.
Sonst nix. Dann ist es typischerweise das
Patchwort. Ja, ich patche ein kleines
Detail einer existierenden Ressource, wenn ich zum Beispiel
aber sagen würde, boah, ich hab dieser Blog existiert zwar, aber
ich schreibe den ganz neu, also neuer Titel, neuer Content und
auch neue Tags, ja dann würde ich einen Put machen, Put heißt
Update, aber die gesamte Ressource zusammen, Patch immer
einen Teil der Ressource und Put immer die gesamte Ressource
updaten und dann habe ich. Ich noch das Wort delete ja,
also das http wort delete und wenn ich wenn ich delete
aufrufe, dann gebe ich typischerweise noch eine in der
URL die id mit, sonst lösche ich alles.
Es gibt also keinen delete. Das wäre schlecht, wenn es das
gäbe. Offen nicht jetzt die Lead
Blocks sagen würde, dann wären sie alle weg.
Ja so also da sagt man dann normalerweise die Elite Slash
Blogs und dann muss man noch mal Slash und die ID angeben und
dann ist halt was weg, ja. Und HTTP, du hast es jetzt
einfach so gesagt, da halt die HTTP.
Methoden liegt daran, weil Rest AP speziell ne ne APS die mit
dem HTTP Protokoll funktioniert oder dafür gebaut ist.
Exakt den Zusammenhang haben wir noch gar nicht haben.
Wir noch gar nicht, erklärt. OK.
Ja, ich hatte so n bisschen flapsig am Anfang gesagt, dass
halt Web Apis Arrest AP is fürs Web sind und da, weil wir für
Swebs sind, ist halt http und naja und dann ist es halt.
Den Übertrag hab ich nicht gemacht an der Stelle.
Das ist gut, dass wir das nochmal gesagt haben.
Jetzt würden wir, die hab ihn noch ein bisschen mehr aufbauen
als jetzt, nur zu sagen Users und Blogs, ja jetzt könnte es ja
so sein, ich möchte zum Beispiel von einem bestimmten User die
Blogs lesen, ja. Also das wäre dann in der
typischen ne also ich ich weiß zum Beispiel der Gerrit, der
schreibt immer coole Dinger und dann hätte ich jetzt quasi in
einer UI die anzeigt diese diese Blogs anzeigt, dann würde ich
jetzt irgendwie n Filter setzen wollen.
Zeig mir mal alle an, alle alle Blogs an die der Garrett gemacht
hat ja so und die wie würde man sowas jetzt in der Rest API
umsetzen da findet wenn man es jetzt ordentlich macht dann hat
widerspiegelt die Struktur der URL, also der API auch die
Struktur, die inhaltliche logische Struktur.
Der Ressourcen also würde ich was haben wie Users und dann die
User id. Jeder hat ne einheitliche User
ID, also Garrett vielleicht dann irgendwie 43 oder irgend sowas.
Ja und dann slash Blogs. Also wenn ich jetzt sagen würde
get slash users slash, 43, slash blogs und 43 nun gerade mal
deine User ID varret, dann käme jetzt als Jason Nachricht ist
auch wichtig, aber vielleicht noch nicht gesagt die Antwort
auf eine Anfrage, wenn man es eine ordentliche API macht ist
typischerweise Jason, da hat man auch eine Folge ist ein
Datenformat. So kommt das als Jason zurück.
Alle deine Blogs, ja, typischerweise, wenn es Blogs
ist und ich nicht nur einen Aussuche als Array von Blogs.
Ein Blog ist ein bestimmtes JSON Object und wenn ich jetzt alle
Anfrage, dann werden die einfach in den Ra gepackt der Reihe nach
und zack kriegst du sie zurück. Nur so eine Art Link dann dahin
oder ist das dann schon der komplette Text auch und so
weiter und sofort in diesem Array dann drin.
Der komplette Text in diesem Array da drin.
Ja, also es wird nicht eigentlich noch mal mit Links
und. Gearbeitet, es sei denn, du hast
extrem krasse Daten oder sowas. Ja da da nimmst du was vorweg
was was später kommt. Also wenn man jetzt das
ordentlich designed und es könnte ja sein du bist jetzt n
sehr sehr umtriebiger Autor Gerrit und du hast ich weiß
nicht also ja ne ganz Enzyklopädie von Blogs
geschrieben, sodass der Server erstmal Gigabyte an Daten
runterladen müsste mit diesem einen request davor schützt man
sich mit sogenannten Query parameters die man setzt und
macht eine Pagination das ist normalerweise mit eingebaut,
dass du kommen halt erstmal die ersten 20 oder die ersten 10 und
dann musst du quasi noch mal Anfragen mit ner anderen
pagination die nächsten 10 bis 20 die nächsten 20 bis 30 und so
weiter wenn du große Last hast, ja, das ist Teil auch des Happy
I Designs, ja. Typischerweise wird das gelöst
über die sogenannten Query Parameters, die du noch mit
dranhängen kannst. Aber ich will es nicht zu
technisch werden lassen. Aber das das muss mitgedacht
werden von vornherein ne. Ja, jetzt, wo wir gerade dabei
sind. Welche Query Parameters gibt es
denn noch? Ich hab schon gesehen, es gibt
ja noch andere, dann außer das Pagination.
Die sind ja nicht fertig definiert.
Also was heißt oder gibt es nicht?
Also das ist halt, was du als Autor der Rest Api dir
überlegst. Aber typischerweise werden.
Limits genommen. Einfach hart an Anzahl an
Ergebnissen die rauskommen und es wird auch gerne sortiert.
Ja also desending ascending kannst du gleich mit angeben und
bestimmte Filter ja also kannst du auch Filter setzen, nur mit
dem Tag so oder so ja das macht man, das macht man um die Arbeit
ein bisschen vom Klienten runter zu machen.
Ja da muss man hier muss man beim API Design aufpassen, dass
man gut abwägt zwischen. Wieviel will ich mir anlasten?
Auf der Serverseite zu implementieren?
Wenn ich jetzt so Filter und so weiter hab, das muss ich ja
alles erstmal auf der Serverseite implementieren, da
muss ich quasi meine Anfragen auch entsprechend koordinieren
und SQL Statements machen, die komplexer werden.
Ja oder sage ich OK, das sind sowieso nicht so viele Daten,
ich Klatsch dem Klienten das alles hin und der kann da
schnell sich selber filtern. Ja weil mit javascript habe ich
sowas auch schnell gemacht, da muss man eine gute Mitte finden
sage ich mal. Ja je nach use case.
So, das heißt, dann haben wir jetzt.
Die query parameters auch drinne.
Du hast quasi gesagt, benutze sie ja, wenn man so etwas
designt, man sollte sie mit Bedenken und mit zur Verfügung
stellen, letzten Endes dann an der Architektur oder im Design.
Okay so, dann kommt ein Punkt zu den Eigenschaften von so einer
API. Ja richtig genau, also hatten
wir auch noch nicht gesagt, die ganze Rest API funktioniert
eigentlich nur, wenn sie sogenannte Statel.
Ess Calls macht, das heißt, was heißt denn das?
Also ich habe ja im Notfall einen dicken Server und ganz,
ganz viele Klienten im Internet verteilt, die alle gleichzeitig.
Und wild clickend irgendwie auf diese API zugreifen, ne?
Und wenn es jetzt so wäre, dass sich der Server zwischen 2
Requests von dem Nutzer irgendein Statement merken
müsste. Also wie soll ich sagen, in
anderen Worten, wenn wenn ich ne Anfrage mache ich als als vor
meinem Browser sitzend als Burkhardt und möchte von Gerrit
irgendwelche Blogposts sehen und mach danach ne Anfrage.
Die nur im Kontext der ersten Anfrage zu beantworten ist.
Dann muss sich ja der Server was gemerkt haben.
Zu mir zum Burkhard. Ja, ich bin aber einer von
vielleicht Millionen, die da gleichzeitig klicken.
Ja, alleine weil ich schon erzähle, ja das das würde eine
unglaubliche Komplexität auf die Serverseite bringen, da muss ich
mir die ganzen States merken, muss mit transaktions Märkten,
ich muss auf einmal wissen wer ist alles mein Klient und wem
muss ich dann noch was nach bedienen und so weiter.
Deswegen hat man von vornherein ausgeschlossen.
Bei Rest AP. Ist das sowas überhaupt
passieren darf jeder einzelne. Request.
Ob das ein postput Read oder was auch immer ist, gegen die API
hat Stateless zu sein hat in sich abgeschlossen zu sein.
Das heißt ich muss in meiner Anfrage alles an Informationen
hingeben um es zu verarbeiten und bekomme meine Antwort auch
alle Informationen zurück die dazu wichtig sind.
Es hängt nichts mit dem nächsten überein und jetzt kannst du mich
fragen wahrscheinlich Gerrit ja aber wenn ich jetzt wenn ich
jetzt einen neuen Blogspot kreiere und will den dann
updaten, wie geht denn das dann? Dann ist der Kreierungsprozess
ist ein ein Post User Gerrit 42. Ich mache jetzt einen neuen
blogspot, dann schreibe ich den Titel und so weiter hin und was
du zurück kriegst ist die Blog id eine eindeutige id zu deinem
Blog und wenn du den jetzt im Nachgang wieder verändern
möchtest, dann machst du halt einen Patch oder einen Put, je
nachdem gegen diese id und es ist ein eigenständiger Call wo
du alle Informationen zu Änderung nochmal mit abschickst.
Das ist wichtig und so bleiben alle.
Calls von allen Klienten gegen diese Rest API immer einfach und
geschützt und stateless ja ist wichtig.
Das heißt, die Rest AP ist eigentlich ein bisschen.
Ich will nicht sagen dumm, aber die führt einfach immer nur
genau das aus, was ihr da halt gesagt bekommt und man muss sich
dann quasi im Frontend oder an anderer Stelle, wo der Call
gemacht wird, letzten Endes die Gedanken darüber machen, was ich
dort aufrufe. Also die API.
Ist mal fix und kann nicht mitdenken.
So perfekt formuliert ausgedrückt.
Ja nein ist genau richtig. Ja, es ist tatsächlich dumm, es
wird, es wird mit Absicht dumm gehaltene Server um das einfach
zu machen genau und wenn du wenn du state haben willst, dann
musst du es halt in einem Frontend machen, der Klient muss
dann sagen okay jetzt habe ich es kreiert, das muss ich mir
jetzt merken, also der State der bleibt beim Klienten und das ist
viel einfacher und besser aufgehoben auch ja und da habe
ich sowieso meistens javascript um mich rum und jetzt zeige ich
dem Garrett irgendwie ein Fenster an wo er irgendwie
nochmal tippen kann. Genau das passiert dann beim
Client. Alles klar, cool, dann weiter im
Programm. Weiter im Text.
Genau. Cacheable hast du noch drauf
geschrieben? Cashewbill ist wichtig, passiert
aber automatisch. Brauchen wir gar nicht so viel
zu sagen, weil es im HTTP ist. Wenn du jetzt zum Beispiel
einmal eine große Liste der Blogs abgefragt hast und machst,
das würdest du es quasi per Klient nochmal tun, dann wenn
man die richtigen Cache Einträge setzt, dann schneidet.
Der dann wird der Core schon abgeschnitten und du kriegst
quasi aus dem Cash das zurück und es wird gar nicht gegen den
Server gecycelt und sparst dir einfach eine ganze Menge an
Daten hin und her gefupt werden, ohne dass es nötig ist.
Ja, das macht das Caching, das funktioniert hervorragend, also
das ist auch funktioniert viel besser bei Rest AP is als es bei
Soap oder Graphql funktionieren kann, weil wir auch noch diese
Endpunkte haben, da kann sich der Browser sehr gut merken.
Was hast du schon mal aufgerufen und was nicht und so weiter.
Genau. Ich mache direkt weiter im
Cashing war jetzt quasi auch eine eine Seitenerscheinung von
Rest API is. Was noch wichtig ist, ist die
Art und Weise, wie wir vom Server mitgeteilt bekommen, ob
wir auch ja auf ob unsere Nachfragen gegen die Rest API
auch irgendwie cool sind oder nicht.
Und es ist standardisiert, also bei den bei den Anfragen nimmt
man quasi die http verben haben wir ja schon gesagt, Post und
Cat und so weiter und bei den Antworten bekomme ich http
statuscodes und die sind auch zementiert dieses.
Harting standardisiert, das kann man nachlesen.
Und wenn man zum Beispiel einen Gat request macht, der gut
durchgelaufen ist, wo man eine Anfrage passt und wo ich eine
Antwort bekomme, dann kriege ich einen 200.
Er, so sagt man es immer 200 er heißt OK, cool, hat geklappt,
200 er deswegen, weil 200 ganz genau heißt, ok, aber es gibt
quasi Abstufung von hat geklappt, man könnte auch sagen,
ja, ich mache jetzt einen neuen Blog Post mit dem Post dann und
wenn das geklappt hat und diese Ressource wurde kreiert.
Server, ja, das weiß ja der Server hat die Datenbank
entsprechend upgedatet und so weiter dann schickt er dir ne,
wenn er gut implementiert ist ne 201 zurück.
Ja und nicht nur 200 für OK sondern 201 da steht für created
zum Beispiel ja, die haben halt alle diese Nummern haben halt
alle bestimmte Bedeutungen und 204 wäre zum Beispiel Deleted,
da weiß ich gerade noch aus dem Kopf, das ist zwar, das sind
alles so Sachen für Haste gemacht, cool habe ich
entsprechend reagiert. Und und für das geklappt gibt es
natürlich auch nicht geklappt. 400 ist der Klassiker Kriegste
zurück, wenn du, wenn du zum Beispiel eine schlechte Anfrage
gegeben hast. Also wenn wenn der Inhalt bei
einem Post request zum Beispiel muss, ja der wird der Inhalt
vorgegeben vom Server und wenn du da irgendwie Kauderwelsch
schickst, dann kriegst du einen 400 er bat request oder wenn du
nicht authentifiziert bist und willst damit arbeiten, kriegst
einen 401 er, das heißt an Authorized und so weiter oder
wenn du einen Rest API Endpunkt benutzt, den es gar nicht gibt,
also. Wenn du nicht Users ID blogs
Nest machst, sondern du schreibst hast n Typo drin und
schreibst Users ID Blog. Ja, dann kriegst du n 404 wie
bei jeder normalen Webseite, die es nicht gibt, da Not found ja
so und dann das schlimmste was du kriegen kannst ist n
fünfhunderter. Fünfhunderter heißt, der Server
hat sich irgendwie abgehängt. Ja der hat nen internen Fehler.
Ja das ist immer da kannst du dann nichts machen als Klient,
da kannst du ja dann anrufen beim Dienst.
So kannst du sagen hier also irgendwas ist da bei euch in der
Implementierung komisch, sollte nie.
Vorkommen 500 witzig. Das ist dann also sozusagen
vorausgesetzt, die Rest API läuft sag ich jetzt mal.
Kriegst du auch irgendwas zurück, es kann aber sein, dass
es dir quasi sagt, dass das was hinter der Rest API kommt,
meinetwegen Datenbank oder so. Ist halt gar nicht erreichbar,
oder? Oder ist halt abgeraucht oder
was auch immer. Ja genau.
Und wenn der wenn deins, wenn dein Server überhaupt nicht in
der Lage ist dir eine ordentliche Antwort
zurückzugeben, so, dann ist meistens so implementiert, dann
kriegst du noch einen 500 er, das heißt so viel wie ich hänge
hier irgendwie total schief, du hast wahrscheinlich alles
richtig gemacht, aber ich bin hier irgendwie abgeraucht
gerade. Perfekt.
Dann haben wir auch die Status Codes.
Muss ich da denn irgendwas für tun oder ist es einfach so, wenn
ich den Rest abid Designer, muss ich das nochmal irgendwie hin?
Oder gibt so eine Art Framework dafür, dass ich, dass das
erstmal für einen schon gelöst ist, eigentlich bei den ganzen
Sachen jetzt. Eigentlich ist erstmal gar
nichts gelöst. Ja, du musst ja das alles schon
schön dahin schreiben und so weiter ja, also wenn man also es
gibt natürlich Frameworks, die nehmen dir viel Arbeit ab und es
gibt auch Co Generation zum Teil, aber ich sag mal wenn du
jetzt nen so n ganz standardmäßiges Framework nimmst
wie es die halbe Welt nimmt, Express js also NO js quasi so n
Server schreibst. Und du hast dir diese API
designt und dann musst du dir quasi, dann schreibst du im
Prinzip diese Endpunkte auf, so kann man es sich wirklich
vorstellen. Also im Backend Code sagst du,
dann schreibst du quasi als Drink diesen Backend Code hin
mit Parametern und dann musst du die Business Logik dazu
schreiben, nämlich den Datenbankaufruf oder was auch
immer du da tun musst. Ja und dann musst du irgendwann
wieder die auch die Response formulieren, also die Antwort,
das ist quasi eine Funktion, eine Funktion kommt rein und du
kannst dann quasi auslesen was will der von mir der Klient ich
mache das was ich tun muss. Dann schick ich ihm auch gleich
wieder die Antwort und da musst du schon selber das alles
programmieren. Ne, also du musst schon diese
ganzen Statuscodes setzen, so das ist schon deine Aufgabe, das
ist Teil der des IPI Implementierungs fortgehens ja.
Gut, dann kommen wir zum Versioning.
Hast du als nächsten Punkt dabei?
Ja genau vergisst man oft, wenn man einmal schnell eine API
macht, dass man, und da habe ich jetzt auch so gesagt, ich habe
jetzt gesagt, die API hat halt einen Endpunkt.
Users und Blogs und so weiter so und wenn ich jetzt aber das
übliche Problem irgendwie, das entwickelt sich weiter, wird ein
total krasses Ding. Irgendwie ist die Blogseite
überhaupt und ich will noch mehr Features hinzufügen oder
irgendwas ändern, ja dann hänge ich schon drin ja weil ich weil
jetzt ja jetzt weiß ich schon gar nicht mehr, ich bin ja nur
ein Serviceprovider, ja ich habe ja quasi nur die apis in die
Welt gepustet, ich kann ja schon sein, dass irgendwie
hunderttausende, von denen ich gar nicht kenne.
Klienten irgendwelche us drauf gebastelt haben und meinen kam
so nutzen wie es ist. Ja kann also jetzt nicht
leichtfertig hingehen und irgendwie die Endpunkte, die
Definition. Endpunkte ändern ja, selbst wenn
ich es dringend nötig hätte, ja, irgendwie ja.
Und deswegen versioniert man sowas gerne.
Ja, damit ich die Möglichkeit hab zu sagen, OK liebe Leute,
hier gibt es jetzt Version 2. Ja version 1 lassen wir da so
ist so ist Old crepe so, aber Version 2 ist richtig coole neue
Features und das mache ich typischerweise gleich ganz am
Anfang ich es ordentlich mache, also fange ich gleich an mit v
1. Also ich nenne die Version quasi
meine App als allererstes als allerersten Pfad dieser dieser
Endpunkte. Also würde in der.
Besseren Praxis würde ich sagen v 1 Users ja dann nicht.
Safe ja und wenn ich irgendwann in Zukunft denke okay ich
brauche was zweites, ja dann bringe ich halt v 2 Users raus,
kann ich schon mal machen so während und die ganzen alten 100
000 Dinger die mich nutzen, die funktionieren ja trotzdem, weil
die Halt gegen V 1 Arbeiten gängige.
Praxis? Ja, das ergibt.
So macht man das, weil Versionierung in der Rest API
funktioniert, quasi indem man einfach die Version vorne dran
klatscht. Ja, weil der, weil der Vater
immer beschreibend ist. Ne genau OK, weiter geht es.
Was gibt es noch für Rispractices?
Genau, es gibt Best Practices genau am Ende eine andere Best
Practice ist. Jetzt kommt es ein bisschen
drauf an, was habe ich da? Will ich jetzt wirklich public
public sein? Das sind wir meistens nicht,
weil du bist ja auch eine Ressource im Web, ein Server der
kann halt auch nur beliebig viele Klienten gleichzeitig
annehmen usw das heißt? Ich muss mir kurz ein bisschen
Gedanken machen um Security und Security hat was zu tun mit
erstmal vielleicht Authentifizierung und
Autorisierung. Also vielleicht darf nicht jeder
meine API einfach benutzen, sondern muss sich halt
einloggen, da gibt es Mittel und Wege wie ich das Avast API
machen kann. Typischerweise macht man das
sehr schick über sein sogenanntes Beerer Token, da
schicke ich quasi. In da gibt es quasi login, Rest
API Calls und da schicke ich sogenannte Tokens mit.
Das sind dann Jada WT Tokens von O aus 2 und so weiter und so
weiter das machen wir heute nicht, aber das kann ich halt
mitdenken und dann habe ich quasi einen Login Mechanismus.
Vorne vor und ich kann halt meine User, kann ich quasi so n
Token in die Hand geben und dann müssen sich jede Anfrage mit so
nem Token machen. Das hast du vielleicht auch
schon mal gesehen Gerrit, man kann ja manchmal mit so freien
API spielen und dann kriegt man irgendwie für ach 7 Tage
vielleicht so n Token oder Irgendsowas und mit diesem Token
kann ich halt quasi Anfragen machen und dann kann ich
natürlich noch die die Rates limitieren, das macht man
typischerweise auch, also der Server macht das dann, da sagt
man halt okay von diesem einen Klienten mit dem Token ZB.
Kannst du nicht mehr, als nimmst du nicht mehr als eine Request
pro Sekunde an oder 5 Requests pro Sekunde an.
Da schützt dich davor, dass dich jemand einfach zu Tode foltert,
quasi mit Anfragen. Ja, weil wir haben quasi sonst
als Server keine Hand da drauf, wie viele Anfragen reinkommen,
skaliert das dann quasi ein bisschen.
Darüber muss man sich eigentlich auch Gedanken.
Machen ja, an diese Limits bin ich schon gelaufen.
Mit unserem App Builder und hab da öffentliche Apis eingefragt
und wurde dann nach kurzer Zeit ja gelimittet.
Ja genau, ganz genau. Das ist auch ganz gut, dass man
gelimited wird. Ja, das ist ja, das hat ja Hand
und Fuß, denn sonst. Das nennt man in der in der
Fachsprache Denial of Service Attack.
Das heißt, ich versuche einfach, ich will gar nicht eigentlich
inhaltlich irgendwas haben von der West API, ich will sie
eigentlich nur totlegen und nehme mir quasi den Call raus,
der also sehr viele Daten, zum Beispiel Zurückliefert und macht
den Halt quasi so oft wie ich kann, dann bringe ich halt den
Server in Schützen dahinter mit der Intention die
Nillaufservice, dass quasi der Service, dass der Server stirbt
und den anderen Klienten zum Beispiel einen 500 er liefert,
weil er nicht mehr kann. Dann ist quasi dann ist quasi
dieser Service da und wie man so schön sagt, ja und davor will
man sich schützen. War nicht meine Intition.
Ne, genau hast du das bestimmt nicht geschafft, wenn es vor
allen Dingen wenn es ein Raid limiting gab.
So du hast noch 2 Punkte. Auf der Liste ja.
Bisher hatten wir 10 das error Handling und Messages.
Ja was ist da die Best Practice? Ja, also das Error Handling ist
schon schon zum Teil abgefrühstückt.
Wenn du gute Error Status Codes verteilst, hatten wir ja schon
ne, also in den 400 zum Beispiel sind die also alles was nicht
200 ist zeigt schon an, du hast ja irgendwie ein Problem.
Und dann kann man natürlich noch für denjenigen
Softwareentwickler, der irgendwie denkt, er macht das
richtig und funktioniert irgendwie nicht, hilft es, wenn
man so ne Art. Error Nachricht einfach verpackt
in die Antwort. Ja wo drin steht hier?
Ich erwarte von dir, dass du irgendwie den Titel noch dazu
packst. Schick mir bitte keinen.
Neuen Blog ohne Titel ja, ich brauche den Titel so.
Du kannst natürlich sagen 400 ja bat request und sonst nix, ja
dann musst du erstmal auf die Suche gehen als Entwickler, was
hast du denn falsch gemacht? Aber wenn du eine Antwort schon
steht einem missing the Title, dann weißt du Bescheid ja also
das ist dann auch gehört auch zur Best.
Practice macht man Szenen Entwicklern einfacher.
Genau dann gibt es noch, da gibt es noch einen Punkt, den ich
hier habe, der ist relativ modern.
Ich habe ehrlich gesagt das noch nicht benutzt beim.
Selber Rest API design. Ich weiß auch nicht wie es
richtig ausgesprochen wird, also htoas wird es geschrieben.
Hey Thorsten könnte man sagen, ich weiß nicht genau wie es
ausgesprochen wird wie gesagt Hypermedia as the Engine of
Applications date, das ist glaube ich immer dann sinnvoll,
wenn du eine relativ verwobene und große Rest API hast.
Und hier ist die Idee, ich formulier noch mal die Idee,
dass der Server quasi in dem der Server die nächste URL mitgeht,
die sinnvoll sein könnte oder mehrere URLS mitgibt.
Schon in der Antwort auf die Vorhergehende kann der Klient
quasi dynamisch weitere Informationen.
Zusammenhängende Informationen sich abziehen ja, also das ist
im Prinzip ne Vereinfachung für den für den Klientennutzer, denn
man kriegt quasi in einem Request, wenn man zum Beispiel
alle Blogs kriegt oder irgendsowas kriegt man dann
quasi ne Antwort aller Blogs noch ein Vorschlag.
Hier kannst du dann vielleicht noch alle dazugehörigen Users
rausziehen. Mit dem und dem Request und so
weiter der steht da quasi drin als als Endpunkt.
Ja kurz gesprochen, so funktioniert das.
Alles klar? Dann haben wir deine 12 Best
practices schon durch. Ja, das heißt schon, aber ich
denke auch, das können wir alle in der Rest API Design,
zumindest wissen wir was was dabei zu beachten ist.
Ich hoffe ich weiß nicht genau was du noch hast.
Ich hab noch mal ne Frage weil ein Thema kommt häufig auf das
ist Rest Full. Also das hört man immer mal
wieder. Restful API oder so was.
Wofür steht dieses Full an der Stelle?
Hat das eine bestimmte Bedeutung?
Ja, ich. Es steht eigentlich für das, was
wir heute definiert haben, also während Rest als Standard quasi
gar nicht so viel mit. Definitiv.
Wir haben ja heute, wir haben so n Paar Best Practices genannt.
Ja, also es ist immer noch Rest. Auch wenn ich get Users nenne
und nicht users, ja. Es ist auch immer noch Rest,
wenn ich XML, zurückspiele und so weiter und sofort ja.
Restf Full heißt eigentlich nur Folge diesen diesen groben
Prinzipien, der Rest API und das Full glaub ich steht
hauptsächlich dafür stateless ja.
Also ich hab hier ne API wo ich volle Anfragen und volle
Antworten zurück kriege und und kein Statement wird auf dem
Server und so weiter das ist diese Art und Weise.
Ähm, dieser entkoppelten gidempotenten, weil es ist auch
so n so n so n so n Fachbegriff kann man selber mal googeln,
idempotenz spielt da auch rein mit, diese stateless ne, also
dieses. Art und Weise der Statelessen.
Kreierung und Umgehens von von, von von Ressourcen ne, das heißt
das Restfull ja heißt das auch nicht.
So, und dann hätte ich noch ne Frage zum Thema API
Dokumentation und Du hast das sicherlich auch vorbereitet, da
hat man immer wieder das schöne Wort Swagger.
Ja, das ist richtig. Swagger, Swagger, ich glaube,
früher hieß es nur Swagger, heute heißt es, jetzt muss ich
aufpassen, Open API nenne ich open AI.
Swagger ist auch in einen Standard übergegangen, also man
hat sich, ist ja schick, also wenn man sich jetzt erstmal
überlegt, dass eine Rest API gibt, was ja eine
Standardisierung ist für einen, für einen, für einen Dienst,
dann kann man sich auch überlegen, wenn ich jetzt zum
Beispiel so eine API ausgedacht habe für die Blogs, wie
dokumentiere ich das überhaupt? Ja, ich muss es ja den den
Entwicklern und den Nutzern der API irgendwie ja auch klar
machen, was kann ich damit alles machen, ja, und da kommt Swagger
ins Spiel und Open API. Ist quasi ne Art und Weise ne
standardisierte Art und Weise wie ich APIS beschreibe.
Rest APIS im speziellen ne und das wird typischerweise gemacht
in einem yammel Format oder einem json Format, das heißt ich
hab quasi eine Dokumentation der gesamten API in einem großen
Pfeil, das kann es auch wahrscheinlich auch in mehrere
Files aufteilen, aber am Ende des Tages also definiere ich das
einmal runter und weil das standardisiert ist, ist das auch
ganz cool, gibt es halt zig toolings drumherum.
Die dir das dann gleich aufbereiten.
Da kannst du quasi so einen Swagger file oder einen Open API
spezifikations File deiner API hinterlegen auf wieder anderen
Diensten und die rendern dir dann quasi super schön wie eine
Dokumentation deiner deiner Rest API im Web.
Schon da können die Entwickler gucken was ist los und wenn das
richtig cool gemacht ist und du alles vollkommen auf die
Authentifizierung und so weiter im Kleinsten niedergelegt hast
als subscription kannst du es direkt live ausprobieren auch.
Kannst du sagen, OK, ich meld mich da halt an und ich trigger
quasi direkt. Siehst du mal.
Ich weiß nicht ob du schon mal gesehen hast, Gerrit, da stimmt,
hast du diese Buttons, da steht dann drauf Get und Post und so
weiter das ist so n typisches Tool davon ne und dann kannst du
es direkt ausprobieren und du siehst direkt die Antwort unten
im JSON, das wird dann immer irgendwie dargestellt.
Was jetzt? Die Antwort war von auf diese
API request. Ja ist ultra cool, ja.
Das heißt, wenn ich etwas in diesem Open API Standard
definiert habe, kann ich mit Swagger in der Form testen, wie
du es gerade beschrieben hast. Genau.
Und du kannst sogar noch viel krassere Sachen machen.
Also kannst erstmal natürlich testen und dann kannst du auch.
Es gibt so Swagger Code Generations, du kannst dann
quasi so ne Art SDK runterladen, also man kann sagen zum Beispiel
ich möchte. Dass mein Kunde, der meine API
bedient, gar nicht selber mit irgendwie mit mit HTTP calls
darum Hühnern muss. Ich möchte ihm quasi eine
Bibliothek bieten in seiner Sprache n Javascript zum
Beispiel im Browser ja und dann dann halt dann gibt es quasi den
Block. Klienten ja, den Maikul Block
Client so und den kannst du dann direkt runterladen und der wurde
generiert aus Swagger heraus. Coach Generation ne und dann
dann hast du da, dann ist das wie n normales Objekt in der die
programmiere wissen dann was los ist und dann hast du quasi
diese. Diese diese Posts und Get und so
weiter Calls, die heißen dann auf einmal Get Blocks.
Ja, dann wird es tatsächlich in ne Funktion umgebaut, weil hier
willst du jetzt Funktionen haben, hast du n Client Punkt
getblogs oder Client Punkt create Blog und dann in die
Funktion schreibst du schon rein title doppelpunkt.
My title Komma content doppelpunkt bla bla bla bla bla,
bla bla und so weiter Klammer zu Abfahrt und dann ist schon
fertig. Ja brauchst du es nicht mehr so
händisch in Eiern ne. Das ist, das ist auch n Vorteil
davon diesen Tools ja das dann also.
Das heißt, du brauchst damit STK Software Development Kits oder
was war der Name jetzt? Ja genau und das heißt die Rest
API ist ne Vorstufe von von von der SDK quasi ja.
Genau, also du kannst also, wenn du eine Rest API hast, dann hast
du ja und die vollständig beschrieben hast, dann hast du
eine vollständige Beschreibung deiner Application.
Da ist deines Application Interfaces.
Dann kannst du also auch eine Hochspezifische andere Software
machen, die diese über diese Schnittstelle quasi deine
Software bedient. Ja, und das nennt man dann SDK.
Und dabei hilft Swagger unter anderem.
Dabei helfen Tools von Swagger zum Beispiel.
Man muss das nicht selber programmieren, dann definierst
Du das einmal hin, das sollte man sowieso machen.
Also ich würde jetzt hier mal sagen, wer eine West API
designed, der sollte auch sein Open API File in Shape haben und
also und dann kriege ich sowieso erstens weiß ich sowieso
dokumentieren muss, zweitens weil es der Standard ist.
Und drittens, weil ich ganz viel Tooling umsonst Kriege und
meinen meinen Kunden, quasi meinen Nutzern, von meiner API
Daten großen Gefallen tun kann. Dann habe ich das verstanden.
Ist gut. Gibt es noch was, was wir zum
Thema Rest AB noch besprechen müssen?
Ja, ich bespreche immer gerne eine Sache, eine Limitierung,
einer Rest API also, die funktioniert immer gut.
Wenn wir genau das machen, was wir heute besprochen haben, ne,
also wenn wir so blogeinträge machen und die verändern und so
und also so einfache Quad Sachen, ja, davon gibt es ja
auch sehr viele und es deckt sehr viel ab, ja.
Wo wir aber immer ins Schwimmen geraten mit dem Rest.
API ist, wenn wenn wir in ganz anderen Use Case haben, wenn
quasi auf der Serverseite, also wenn sie Ressourcen sich
hochfrequent ändern und wenn ich als Client das mitbekommen
möchte. Also wenn ich so ne Art
Subscribe Publish Subscribe pattern habe, ja.
Also ich sag mal was, also wenn ich zum Beispiel Aktien ja wenn
ich jetzt zum Beispiel ne arrast IPI machen möchte, wo ich
irgendwie in in Echtzeit die Änderung von Aktien.
Kursen über mehrere Aktien, ne zum Beispiel verteilt irgendwie
haben möchte. Ja das wird unglaublich hakelig
mit einer Rest API. Ja weil das nicht weil es in der
in dieser ganzen Architektur nicht vorsieht, wie ich mich als
Klient. Gegen ein Event auf dem Server
subscriben kann, um benachrichtigt zu werden.
Also es gibt nicht die Idee eines Push einer Push
notification quasi. Ja und Gerrit, Du weißt jetzt
auch warum, weil das ist es passt auch nicht so zum Design
ja weil wenn ich sage ich bin halt irgendwie stateless.
Und ich will. Ich bin total dumm und ich will
nichts wissen. Ja von meinen Klienten, dann
passt es auch auf einmal nicht so gut dazu zu sagen, Ah, der
Klient hat sich jetzt Subscribed gegen Events, dem muss ich und
dem und dem und dem anderen auch noch und diesen anderen 3000
auch noch, den muss ich irgendwie die und die und die
und die Events schicken, die wollen die halt irgendwie haben,
dann fängt es nämlich doch wieder an irgendwie Komplexität
aufzunehmen auf der Serverseite und deswegen ist das dafür nicht
ganz so geeignet. Ja, es gibt Mittel und Wege,
aber es sind alles, es gibt also so long polls und.
Du kannst dann Websockets einziehen und so, aber das würde
ich sagen, ist ja das erweitert die Rest API um das was sie
eigentlich ist, als als was sie standardisiert ist.
Gehört nicht so gut zum Standard dazu und deswegen ist es auch
nicht. Nicht so standardisiert, wie man
das machen kann. Ja, und hier kurz noch mal ne
Differenz zu Graph QL in Graph QL ist das vorgesehen nen Graph
QL gibt es ne subscription ne? Und da ist quasi Technologie mit
Eingebordet quasi ins Graph QL. Das ist mir sehr einfach, macht
mich genau gegen Events zu registrieren.
Ja und dann ne Nachricht zu bekommen vom Server ist bei Rest
API nicht trivial. Ja das nur noch einmal so als
kleiner Displaymer, da muss man zweimal dreimal drüber
nachdenken. Wenn ich jetzt eine Rest API
haben will. In der auch der Use Case
vorkommt, dass mir ne Klienten relativ häufig.
Abgeleitet werden müssen ja, weil wenn ich die jetzt Pollen,
also mit einer Rest IPA, müsste ich die Pollen lassen, dann frag
ich halt andauernd mit dem Get ja.
Alle Sekunde irgendwie so und dann und dann merkst du schon,
das führt genau zu dem Problem, was wir vorher gesagt haben.
Load reduction so ja wir, wir wollen eigentlich nicht, dass
die Klienten in hoher Frequenz uns anfragen, wir wollen das
eigentlich reduzieren und cashen und so weiter also da beißt sich
die Katze in den Schwanz, da muss man dann n bisschen gucken
was man macht. Ja, alles klar, ist doch gut,
das ist doch noch mal die Limitierung aufzeigst wir haben
ja auch schon folgen gemacht zu anderen Möglichkeiten grpc Vrpc
von von uns quasi. Verlinkt man nochmal.
Die Folgen müssen wir jetzt aber nicht nicht erklären.
Aber wichtig ist zu wissen, dass.
Das Pattern, Subscribe oder oder Publish Subscribe nicht geeignet
ist. Ja ist einfach nicht dafür
gemacht. Ist so ganz genau so kann man es
sagen. Perfekt noch was buckert oder
sind wir durch? Ich glaub, wir sind wir sind
durch. Wir haben auch schon wieder
lange gesprochen, also lass uns die Hörer wieder ausruhen.
Alles klar, cool okay dann ja, machen wir Schluss für heute und
bedanken uns fürs Zuhören. Würden uns freuen natürlich über
positive Bewertungen und so kommen wir schon fleißig und
auch Kommentare kann man dazwischen bei Spotify und Co.
Abgeben. Danke Leute.
Bis in 2 Wochen ciao so. Sieht es aus, bis denn Tschüss
aus Hamburg. Einfach komplex wird präsentiert
und produziert von Heissenware. Wir freuen uns auf deine Fragen
und deinfeedbackanpodcast@heissewerbung.com
vielen Dank fürs Hören dieser Folge bis Dienstag in 2 Wochen
und Tschüss aus Hamburg.