REST API: Grundlagen und Design Best Practices #66

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 [email protected] vielen Dank fürs Hören dieser Folge bis Dienstag in 2 Wochen und Tschüss aus Hamburg.