Transkript: REST

Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python Podcast.

Heute in der 29.

Episode.

Wir machen heute Reste, äh, Rest, ähm, Representational State Transfer.

Was ist das eigentlich?

Und hier ist der Dominik und ich bin da mit dem Jochen und heute wieder mit dem Johannes.

Hallo Dominik.

Hallo Johannes, hallo.

Ihr kennt uns ja vielleicht schon, wenn ihr gehört habt.

Wir waren öfter schon mal in dieser Konstellation.

Das heißt, wir stellen uns heute nicht vor.

Aber wie gesagt, wir machen Rest, Representational State Transfer.

Und ja, wen frage ich denn zuerst?

Was ist denn das?

Ja, ich dachte, wollen wir nicht vielleicht zuerst den News machen, weil ich habe da auch noch so ein Tür.

Nein, nein, nein, wir wollen erstmal kurz das Topic erklären und dann machen wir News.

Da kommen wir nicht mehr zu den News.

Doch, wir kommen noch zu den News.

Na gut, okay, machen wir sicher nicht.

Erklär mal ganz kurz, was REST ist.

Erklär mal, aber nur ganz kurz.

Ja, Elevator-Fischung.

Also, man stellt sich vor, man hätte da so eine Dampfmaschine.

Naja, warte mal, das war es das andere.

Also Rest ist, also ich glaube, das beste Beispiel für, wie kann man sich das vorstellen, was das eigentlich ist, ist, man nimmt halt irgendwie das Web.

Das ist ja mal krass.

Man hat, genau, das ist das Web und dann hat man dann so einen Browser und das ist eigentlich Rest.

Also das Web ist schon Rest.

Okay.

Okay, News.

Ich erkläre das immer anders.

Ich erkläre das immer im Unterschied zu dem, was es nicht ist.

Und was man früher gemacht hat, um APIs zu machen, war LPC, Remote Procedure Call, wo man halt Funktionen hatte, die man aufgerufen hat mit irgendwelchen Daten.

Und REST ist jetzt eben nicht Funktionen, die man aufruft, sondern Objekte, die man abruft und verändert.

Und das ist für mich so der Knackpunkt, was REST zu REST macht.

Dass man nicht Funktionen aufruft, sondern Objekte abruft und verändert.

Okay, jetzt rufen wir jetzt Objekt-News ab.

Jetzt machen wir News.

Ja, jetzt machen wir News.

Gut, okay, machen wir News.

Pattern Matching.

Pattern.

Genau, Pattern Matching ist auch tatsächlich der erste Punkt, den ich ja auf der Liste habe.

Alle anderen Punkte sind unwichtig.

Pattern Matching.

Hast du da eigentlich dir schon mal Gedanken gemacht über Pattern Matching?

Nur ganz am Rande, ich habe sogar, ich fand das so gut, dass ich direkt einen Blogartikel auf meinen selten benutztes Blog geschrieben habe, weil es so wichtig ist und so toll, dass ich, ja klar, kriegt ihr natürlich einen Link dazu, dass ich das sofort schreiben musste.

Und Patternmatching ist so ein Feature, was es in anderen Sprachen, in vielen funktionalen Sprachen gibt, was man auch da kennt.

Und wenn man das einmal gesehen hat, dann kann man nicht mehr ohne.

Und ich habe früher an der Uni funktionales Programmieren gelernt und gemacht und war dann etwas schockiert, als ich zu Python kam und die hatten das nicht.

Und hab's aber irgendwann vergessen, dass es das in Python nicht gibt.

Und jetzt ist es.

Also jetzt das erste

Anbieter so gewesen, ja, aber es gibt auch if-else, warum brauche ich denn dann ein Switch Case?

Ja, das ist prinzipiell richtig.

Man kann das alles mit IF-Ls machen.

Man kann auch prinzipiell jede Schleife aus While-Loops machen, man kann prinzipiell auch alles aus Goto zusammenbauen.

Man macht es nicht, weil das nicht gut ist.

Und weil es bequemere Dinge gibt.

Und gerade jetzt das Pattern Matching, was in Python reinkommt, ist meiner Meinung nach ein sehr mächtiges Pattern Matching.

Die können matchen auf Typen und auf Werte und die können Variable Capture machen, wo eben so ganz komplizierte Fälle, die ein sehr langes IF wären, dann auf einmal sehr einfach abzuschreiben.

Was ist ein Variable Capture?

Capture.

Was Pattern Matching macht, ist im Wesentlichen ein If, wo ich nicht hinschreibe, dass eine Bedingung wahr oder falsch ist, sondern ich schreibe eine Datenstruktur hin.

Und wenn diese Datenstruktur vorgefunden wird, dann trifft dieses Pattern zu.

Die erste coole Sache, die da passiert, ist, dass man nicht mehr irgendwelche Dictionaries.get machen muss oder irgendwelche Listen gucken muss, ob die Länge größer 0 ist und dann das erste Element rausholen, sondern man schreibt einfach hin, aus der Liste das erste Element soll ein Attribut haben x und das soll den Wert Y haben.

Und wenn diese Struktur zutrifft, dann ist dieses Pattern gematcht.

Ich habe in dem eben genannten Blockartikel ein Beispiel, wo es sehr eindeutig wird.

Variable Capture heißt, dass ich in dieses Muster, was ich hinschreibe, in diese Datenstruktur, nicht nur konkrete Werte reinschreiben darf, sondern ich darf auch Variablen Namen reinschreiben.

Und wenn diese Variablen-Namen gefüllt werden können, dann stehen die mir in dem Branch, der dann aufgerufen wird, zur Verfügung.

Das heißt, wenn ich zum Beispiel sage, das Pattern, was ich schreiben möchte, ist, das erste Element der Liste ist der Float X.

Dann kann ich in dem Branch, der dann zutrifft, auf die Variable X zugreifen und es ist automatisch sichergestellt, dass das ein Float ist.

Also es ist schon gecastet.

Und das heißt Variable Capture, weil eben diese Variable sozusagen aus diesem Muster raus eingefangen wird.

Das klingt sehr nützlich.

Und wenn man das auch mit Typen und so machen kann,

das klingt, das ist super nützlich.

Gerade das erste Beispiel, was man da sieht, ist eben diese Typen.

Wenn ich eine Funktion schreibe, die vier verschiedene Typen annehmen kann, dann schreibe ich jetzt einfach Match Type von X, CaseInt und dann ist es ein Int.

Oder CaseStill, dann ist es ein Stir.

Das ist so viel einfacher, als das mit Ifs zu machen, das ist sehr, sehr schön.

Ja, fand ich auch.

Es gab aber viel Gegenstimmen, muss ich sagen.

Ja, es gab ganz schön Gegenwind.

Es gibt ja schon seit einiger Zeit irgendwie Leute, denen das alles kompliziert wird.

Und ich meine, da gab es ja auch diese große Kontroverse irgendwie beim Walros-Operator.

Auch bei den Typen, bei diesem, bei dem.

Ja, aber die

sind immer 3.10 ist doch irgendwie so eine Muss-Version, oder?

Das ist nicht so eine Kann-Version, was da alles kommt.

Also die Type-Annotations, die dabei sind, dass man einfach hinterschreiben kann, die Klasse beispielsweise, die das sein soll oder deren Instanz das sein soll, ohne dass man da groß Typer importiert und dann kann man so einen Union Operator dahinter setzen, also diesen, ne?

Und dann kann man da zwei verschiedene Typen haben und so, dass es sieht alles total schick aus.

Also ich finde, so wollte ich das schon immer lesen.

Ja, also ich weiß nicht so genau.

Ich meine, bei denen ich finde, diese Type-Annotations, die sind halt an manchen Stellen total nett.

Ob ich das jetzt an allen Stellen im Code gerne hätte, weiß ich jetzt auch nicht durch.

Genau, genau.

Ja, man kann es dann, genau.

Und da, wo man es, da wo es halt Sinn macht, irgendwie, da kann man es dann halt dazutun und dann ist es auch nett.

Ich finde auch tatsächlich, das mache ich in letzter Zeit häufiger, irgendwie entweder Data Classes Atris oder Pydentic verwenden.

Und tatsächlich Klassen so hinzuschreiben, ist deutlich angenehmer, als das irgendwie.

Hatten wir Pydentic schon mal?

Ich habe erfinden,

ich weiß nicht genau, ob ich es mal gepickt hatte oder so.

Kann sein.

Was macht Pydentic?

Du hattest es auf jeden Fall mal erwähnt, glaube ich.

Verlinke es auf jeden Fall nochmal, das ist ziemlich cool.

Ja.

Genau.

Ja, und also ich finde, diese Art, sozusagen, Klassen hinzuschreiben ist sowieso irgendwie, macht irgendwie nett.

Ich sehe, ich habe auch schon irgendwie hier ein Pydentic in der Dokuma rumgewühlt.

Also eigentlich wollte ich wissen, was das ist, aber

ja, das ist so eine Art Mischung aus MyPy und Data Classes, oder Jochen?

Man kann leicht Datentypen definieren mit bestimmten Typen und der prüft die dann auch noch.

Genau, also es prüft es halt auch zur Laufzeit.

Und es ist halt auch so, dass man dann halt so eine eingebaute Serialisierung nach JSON oder so auch mitkriegt, weswegen man es eigentlich auch super für so Rest-Geschichten verwenden kann.

Rest man gleich mal.

Was ist das denn, Jörn?

Ja, Moment.

Erstmal die Reste der News, bitte.

Was haben wir denn da noch?

Ja, so ein Pattern Matching, ja, coole Sache, da sind wir uns alle einig.

Irgendwie komisch.

Naja.

Es gibt neue Releases von UV-Loop und Async PG und so.

Aber da war jetzt auch nichts Weltbewegendes dabei irgendwie.

Aber Async PG ist auch so ein Ding, was man sich unbedingt mal angucken kann.

Ich wollte gerade sagen, wovon hast du gerade gesprochen?

Ja, UV-Loop ist halt so eine schnelle, also ist die Python-Version oder Abstraktion ein Drapper um LibUV und das ist eine super schnelle Abstraktion über den ganzen betriebssystemspezifischen Schnittstellen, sowas wie EPOL oder KQ oder was ich nicht, was das sonst so, TCP-Completion Ports oder I.O.

Completion, nee, I.O.

Completion Ports hat.

Ich glaube, das ist ein mehr Stuff für die Web-Server-Folge, die wir

mal machen.

Ja, ja, genau, aber auf jeden Fall, man kann damit schnell I.O.

machen und das Ganze halt in der Event Loop und das ist auch das, was unter Node.js zum Beispiel drunter liegt.

Und genau, davon gab es jetzt gerade eine neue Version und Async PG ist halt eine Async-Library, um halt auf Postgres zuzugreifen und das ist halt auch sehr praktisch, weil also das normale Psycho-PG, das man so verwendet, kann das halt nicht.

Und eigentlich wäre das ja auch saucool, wenn man das Async machen könnte.

Und Async PG ist auch richtig schnell.

Async auf Datenbanken stelle ich mir schwierig vor mit Transaktionen und so, weil.

Nö, das ist alles, eigentlich ist das überhaupt kein Problem.

Es gibt halt nur einen wahren Zustand dann immer, und das ist egal.

Ja, aber das ist ja okay.

Ist ja okay.

Du hast ja auch sonst auch, du kannst ja schon mehrere Sachen gleichzeitig machen.

Nur ist es ist halt so, dass du normalerweise dann halt warten musst.

Du schickst halt irgendwie ein Settlement an die Datenbank und dann blockierst du halt einen Code.

Du machst du es halt synchron.

Das ändert nicht die Datenbank, Dominik, sondern es ändert nur, wie du die Verbindung der Datenbank hältst.

Aber wo wir gerade bei Psycho Begesian Psycho PG3 ist angekündigt und gerade unterwegs.

Die koordinieren sich gerade mit den Django-Leuten, dass die Datenbankverbindungen da cooler sind.

Die haben zum Beispiel Connection Pooling im Adapter drin.

Das ist auch eine sehr schöne, da hatte ich jetzt letztens so ein Problem tatsächlich auch, dass irgendwie die Connections rausgelegt sind.

Bei Django gibt es, glaube ich, im Grunde zwei Arten.

Entweder man macht halt eine Verbindung pro Request oder man setzt halt das auf irgendeine Zeit oder so und dann wird die Connection so lange aufgehalten.

Aber, und das haben wir halt nicht so klar, oder ich dachte, das passiert irgendwie magisch automatisch und das passierte nicht, wenn man einen Thread aufmacht, dann macht das eine Seite-Connection auf.

Und wenn man sich dann nicht weiter um den Thread kümmert, oder wenn der weggeht, dann geht der Thread weg, aber die Connection nicht.

Und wenn man das häufig macht, dann ruft irgendwann der, dann kriegt man Ärger von dem Datenbank-Admin, weil der sagt, die waren die ganzen Connections dazu.

Was zur Hölle macht ihr denn da?

Ja.

Ups.

Ups, genau.

Ja, ja, aber Pulling wäre auf jeden Fall eine schöne Geschichte, weil manchmal ist ja auch eine Verbindung nicht genug.

Ja, und generell ist es ja gut, wenn da ein paar Verbindungen offen sind, weil man braucht die halt doch häufig.

Ja, ansonsten, was hatte ich noch gelesen?

Es gibt irgendwie, es gab irgendwie einen Artikel zu Security-Geschichten.

Dependency Confusion.

Ich weiß nicht, ob ihr dafür habt.

Da gab es einen Artikel zu.

Es gab da schon ein paar Artikel zu das.

Dependency Confusion.

Ja, sehr deprimierendes Problem, ehrlich gesagt.

Das muss sogar der Kern, das ist Dependency Confusion.

Ja, da gab es doch so ein, da hat doch eine 3.500 Sachen bei PiPi hochgeladen, oder?

Ja.

Und genau, das ist halt so, oft, wenn da Leute die Versionen, die sie haben wollen, nicht explizit festlegen, dann muss man halt nur eine Version haben, die ein bisschen höher ist.

Oder wenn sie sich vertippen.

Oder wenn sie sich vertippen, genau.

Dann kann man das sozusagen hijacken und dann kann man denen Software installieren.

Die auch im Großen und Ganzen das tut, was die erwartet haben, was sie sich installieren wollten, aber halt auch vielleicht ein bisschen mehr oder so.

Also ein Beispiel wäre, wenn zum Beispiel jemand eine Bibliothek hochlädt, die Django heißt, nur ohne D vorne dran.

Und wenn jemand halt dann Django installiert, das geht auch.

Hat auch die gleichen Versionen, aber macht halt gleichzeitig was weiß ich, Bitcoin-Mining oder sonst irgendwas oder Backdoors auf oder sonst irgendwas.

Man weiß es nicht genau.

Und da gab es eben so einen Vorfall, dass jemand dreieinhalbtausend solche Bibliotheken auf PiPI hochgeladen hat, die sehr suspicious waren und die dann auch wieder gelöscht wurden.

Ja, also der Artikel, den ich da gelesen hatte, derjenige, der das gemacht hat, der hat das tatsächlich quasi auch im Auftrag von größeren Firmen gemacht.

Und der hat damit quasi alle großen Firmen aufgemacht.

Also und hat da auch überall irgendwie quasi das habe ich auch gehört.

Diese Preisgelder für gekriegt, die man halt für es schafft.

Ja.

Also das war, das hat sich gelohnt.

Und das ist auch wirklich ein fieses Problem und es gibt eigentlich nicht so, es ist so ein bisschen doof.

Poetry könnte doch da helfen, oder?

Wenn ich jetzt irgendwie die Hashes von den Dependencies da mit speicher?

Nee, nein, nein.

Nee, weil du ja immer noch den Namen eingeben musst, irgendwann.

Ja, aber wenn das in bei einer Pi-Project Hummelton gepinnt ist, richtig.

Dann hoffe ich mal, dass du die richtige, dass du die richtige

gepinnt hast.

Wenn ich das eintrage.

Ja, und jemand muss aufpassen.

Was meinst du mit jemand?

Ja, du siehst es ja nicht, du merkst es ja nicht, das geht ja.

Das funktioniert ja, das macht ja genau das, was es soll.

Nur halt irgendwann auch noch was anderes.

Und wenn du nicht gerade dann drauf guckst,

das ist ja immer das Problem mit irgendwelchen Dependencies.

Also wenn man irgendwie sich sowas wie Kai auf den Redner holt oder Node.js oder was auch immer und irgendwelche Pakete von irgendwo installiert, ohne zu genau zu wissen, was für ein Source-Code denn da drin steckt oder jedes Mal nachzugucken, ob denn da in der neuen Version vielleicht was Falsches drin ist, dann ja.

Ja, das Problem haben wir an vielen Stellen, das haben wir natürlich auch bei Docker zum Beispiel, wenn man sich da irgendwelche Images zieht, wo man nicht weiß, wo da drin ist.

Das Problem haben wir auch bei Distributionen, aber jetzt, wenn man jetzt eine Distribution nimmt und man installiert per abt irgendwas bei Debian oder so, dann kann man ja davon ausgehen, wenn man jetzt nicht, was natürlich auch viele Leute machen, was natürlich auch wieder so ein Ding ist, wo man sich sagen kann, aus Sicherheitsperspektive ist das ganz übel, wenn man da halt irgendwelche Dritt-Repositories reinholt, die kann ja auch alles installieren.

Das ist den meisten Leuten vielleicht auch nicht so ganz klar.

Aber wenn man jetzt nur die Debian-Repositories drin hat, dann kann man ja davon ausgehen, okay, das hat irgendeiner, der das maintained, hat sich das angeguckt, hat geguckt, ob das die richtige Software ist, hat draußen ein Paket gebaut, hat das Ganze signiert und so und dann kann man sich schon relativ sicher sein, okay, das, was da landet, ist tatsächlich nicht irgendeine Malware oder so.

Aber welche Python-Versionen haben die gerade?

Genau, das ist also das ist das Problem.

Ja, so funktioniert.

Und diese ganzen Bibliotheken musst ja dann auch.

Du kannst ja dann nicht mit Pip irgendwas installieren, sondern musst ja dann eigentlich.

Und ich kenne solche Firmen, ich habe Kunden gehabt, die das gesagt haben.

Wir wollen keine Dependencies reinholen von irgendwo her, sondern wir wollen die Betriebssystempakete haben und dann hast du dann echt das Problem.

Ja, dann haben die doch keine Software mehr.

Viele, viele Sachen.

Ja, bist halt bei Django 2.irgendwas.

Eins.

2.0.

Ja, aber ist doch Quatsch.

Also dann mache ich doch lieber irgendeinen Server, auf der vielleicht kompromittiert werden kann und mach dann andere Sachen sicher.

Mach dann Singles Point of Cruise oder sowas und dann habe ich halt die Daten abgesichert über eine Authentifizierung.

Weiß nicht.

Ja, an irgendeiner Stelle musst du irgendjemandem vertrauen und das ist ein Problem.

Und selbst wenn es nur derselbe ist, und das ist meistens der größte Fehler.

Ja, aber zum Thema Sicherheit habe ich auch noch was sehr Interessantes gelernt.

Ihr wisst ja sicherlich, alle, die zuhören, wissen sicherlich, was Course ist.

Cross-Origin Request Safety?

Security?

Oh, das ist eine gute Frage, weiß ich jetzt gar nicht.

Ich weiß es auch nicht, aber ich weiß, dass es das gibt.

Ich weiß, dass es es gibt und ich weiß, dass das sehr gut ist, weil das bedeutet, dass man nicht einfach irgendwoher Ressourcen abrufen kann.

Resource Sharing?

Ah, okay.

Ah, Cross-Origin Resource Sharing, okay.

Das gibt es nicht für Websockets.

Websockets haben keinen Kurs.

Wenn ich einen Websocket irgendwo hin aufmache, dann kann ich darüber alles abrufen.

Oh.

Und das ist.

Ja, genauso habe ich auch reagiert.

Das war mir jetzt nicht klar.

Oh shit.

Aha.

Genau.

Also die Annahme ist, dass der, dass der Server das macht, dass der den Origin-Header überprüft und das dann halt ablehnt.

Aber prinzipiell muss er das nicht.

Prinzipiell kannst du eine Verbindung irgendwo hin aufmachen und sagen, hier, ich bin der Websocket von so und so.

Und ja.

Also das ist doch so eine Sache, wenn das im Header drin stehen müsste, mach dann nicht sowas wie Django Channels, sowas in den Headers mit, ähm, wie nennt man das?

Das weiß ich nicht.

Und das ist genau das Problem.

Und es ist auch, glaube ich, nicht die Aufgabe von Channels, sondern es wäre eigentlich die Aufgabe von dem terminierenden Webserver.

Und auch da weiß ich es nicht.

Und weiß ich nicht, ist in der Sicherheitswelt so viel gemeint.

Das ist, wenn es ist immer, wenn es so ganz überraschend und komisch ist und man es nicht, dann ist es kein gutes Zeichen.

Nein.

Auch da habe ich einen Link gefunden, der das alles erklärt und wie man damit umgeht und so weiter.

Damit verlinken wir einfach.

Aber ich habe zum Kurs was gelesen, in Django Rest Framework, weil die nämlich inklusive Sockets das integrieren wollen mit Kurs.

Steht zumindest in einem Feature.

Ja gut, dann überprüfen die das halt.

Das ist ja sehr gut.

Was uns zu unserem Topic zurückbringen konnte, wenn ihr denn mit den News schon soweit seid.

Ja, das ist nicht mehr viel.

Tatsächlich jetzt hatten wir auch schon mal, da waren wir ein bisschen voreilig, irgendwie hatten wir ja schon 30 Jahre Python gefeiert.

So der offizielle 30 Jahre-Dings, das war irgendwann vorletzte Woche oder sowas.

Letzte, ich weiß nicht mehr genau.

Da müssen wir jetzt ein Glas Sekt aufmachen.

Ja, müsste man jetzt eigentlich.

Ja, ist jetzt Python 30 Jahre draußen.

Hurra!

Dann ist

es ja älter als ich.

Ich wollte sagen.

Genau.

Ich hatte mir mein Geld geklaut.

Entschuldigung, Dominik.

Dann ist es ja älter als Dominik und ich.

Ja, es gibt noch ein zweites.

Ich habe noch einen Versuch für den Witz.

Es gibt ja noch ein zweites Jubiläum.

Die Python Software Foundation ist 20 Jahre alt geworden.

Und die ist dann ja älter als ich.

Okay, verdammt.

Das funktioniert nicht beliebig nach unten.

Wir nehmen dir alle ab, dass du erst 19 bist, Jochen.

Die ganzen Geschichten, wo du über Computerspiele aus den 90ern erzählst, ist es alles nur, was du gehört hast, was du gelesen hast.

Genau.

So eine Tarnung.

Ja, wenn man letzten Montag in einem Schaltjahr geboren worden wäre, dann hätte man tatsächlich das Problem gehabt, dass man wahrscheinlich in seiner, zumindest der Zahl, seine Geburtstage, die man bisher gehabt hätte, deutlich unter diesen Damen gewesen wäre.

Das ist gut, dass du es so formuliert hast, weil sonst hätte ich jetzt direkt meine Mathematiker auspacken müssen.

Mit welcher Formierung habe ich mich gerettet?

Ja, die Zahl der gefeierten Geburtstage, das ist leider.

Meine Goldwaage sagt ja.

Ja.

Ja, gut.

Genau, aber dann.

Achso, ach doch, eine Geschichte habe ich noch.

Oh, das, äh, genau, du hattest es mir, äh, Johannes, du hattest mir, glaube ich, mal so einen Link geschickt auf so einen Benchmark.

Da arbeiten wir jetzt auch schon eine Weile dran, Jochen.

Ja.

Und genau, da ging auch über Hacker News und dann war der auch bei Python Bytes drin und so und da ging es darum, da hat er ja jemand irgendwie, ich weiß nicht genau, was da.

Also da ging es irgendwie.

Jemand hatte etwas gebenchmarkt.

Man hat irgendwas gebenchmarkt, genau.

Und das Einzige, was ich dazu im Grunde nur anmerken wollte, also so ein Körnchen Salz sollte man da vielleicht schon mit dazu tun, sonst.

Also du sagst, man müsste das mal selber machen, ja.

Das ist das, was ich da raushöre.

Genau, also ich meine, ich könnte das ja auch, ich könnte das bestimmt fortsetzen, ne?

Lügen, dreiste Lügen.

Haben kurz.

Nee, halt, warte.

Benchmarks.

Nee, aber ich glaube, das ist mal eine eigene Episode, oder?

Wenn wir mal über diesen Benchmark sprechen, den wir jetzt schon seit drei Monaten in der Mache haben.

Achso, ja, ja.

Der noch keine eindeutigen Ergebnisse gibt.

Du meinst, wir wollen beweisen, dass Python die schnellste Sprache ist unter der Sonne?

Nee, aber vielleicht schnell genug.

Wir beweisen, wie die schnellste, wie man damit schnell sein kann.

Oh, das ist ein

Thema für eine eigene, ich glaube, da brauchen wir wirklich.

Da machen wir eine eigene Geschichte zu.

Okay, ich wollte nur sagen, also wenn man sich jetzt diesen Artikel sich anguckt, vielleicht nochmal nochmal, also wenn man es wirklich wissen will, muss man es selber messen.

Und ja, also es ist nicht so ganz einfach.

Also zum Beispiel eben bei dem Artikel sich dann so anguckt, irgendwie wenn da so HTTP-Todels oder bei CDC ist das dann installiert und dem anderen nicht und HTTP-Parsing kann ja dann das Nadel überwinden.

Also ich will gar nicht gar nicht anfangen davon, stimmt.

Da machen wir irgendwann, wenn wir Ergebnisse haben.

Aber ja, Benchmark ist alles nicht so einfach.

Man kann nur so viel verraten.

Wir haben extra VMs bei einem Hoster gekauft, um genügend Bandbreite und alles zu haben und wir haben sie bisher nicht gebraucht.

Ja.

Gut.

Ja, alles klar.

Ja, jetzt dacht ihr, Entschuldigung, jetzt müsst ihr mir das erzählen, jetzt bin ich sonst die ganze Zeit neugierig.

Der Jochen hat einfach schon sehr viele Dinge ausprobiert und wir haben es bisher nicht geschafft, so viel Bandbreite zu verbrauchen, dass man mehr Bandbreite, also dass wir dass wir ein Netzwerk sinnvoll benutzen hätten können.

Also das war das mit dem Gabit, was du nicht kriegst an ausgelastet.

Was war die erste Zahl, Jochen, die du hattest?

Was war dein erstes Ergebnis?

Wie viele Kilobit hast du.

Ne, nö, das ist schon so schon ein paar Megabyte pro Sekunde, aber halt neu.

Weit entfernt.

Ja, ist noch nicht da, wo es hin muss.

Ja, also es geht darum, dass er halt die Konkurrenz von Python-Web-Applikationen.

Nee, also das Ziel dabei ist eigentlich rauszukriegen, braucht man sowas wie ein Nginx eigentlich noch davor?

Oder kann man das nicht einfach alles jetzt, wo in der schönen neuen Async-Welt, ne, so alle gut, ich meine, das ist halt irgendwie so eine Tradition geworden, dass man da halt irgendwie fürs File-Serving irgendwie ein Nginx davor hat oder das halt über einen CDN macht?

Ja, oder das halt irgendwie von Amazon machen lässt oder so.

Das ist halt irgendwie so, das macht man halt so.

Die Frage ist, gibt es dafür eigentlich jetzt noch so einen Grund?

Weil tatsächlich kann man ja mit Async und der ganzen Syntax und den ganzen schönen Dingen, die es jetzt alles gibt, also man könnte das ja eigentlich auch selber machen.

Die Frage ist halt nur, ist das schnell genug?

Ja, also wenn ich jetzt 100 Gigabit saturieren möchte, okay, dann nehme ich vielleicht doch was anderes, aber wenn ich jetzt sowieso eine relativ, wenn ich jetzt sagen wir mal so, nur so ein Gigabit habe oder so an einem Server, dann kann es ja sein, dass es völlig egal ist, ob ich NGX nehme oder irgendwie Python, weil es ist schnell genug.

Und Gigabit ist ja heutzutage eigentlich gar nicht mehr so wahnsinnig viel.

Vielleicht reicht es ja.

Und das töt ihr weiter in unserer Website.

Genau, dann haben wir das ein bisschen angezeasert, aber genau.

In der Benchmark-Episode.

Wir wollten nämlich noch so eine Datentypen-Folge machen, die haben wir auch noch aufgeschoben, nur für alle, die sich dann nehmen wollten.

Ja.

Im Pennsylvanier.

Ja, ist eine spannende Sache.

Gibt es viele schöne Dinge.

Ich habe noch was zum Thema Webserver, habe ich kürzlich gefunden, Fly.io.

Hab's noch nicht selber ausprobiert, aber das scheint so ein bisschen wie das developerfreundliche HeroCode zu sein.

Mit einfachem Deployment überall.

Nice.

Und wo man quasi einfach Docker-Container hinschickt und die lassen die dann laufen, wo man sie haben möchte.

Und das sah sehr gut aus auf den ersten Blick und der hat auch sehr viele schöne technische Artikel geschrieben.

Also es hat mir gut gefallen.

Ich habe es noch nicht, ich habe noch keine Gelegenheit gehabt, das auszuprobieren, aber ich werde, hat mir vorgenommen, das auszuprobieren.

Ah, sehr cool, weil da gab es nämlich, das habe ich heute irgendwann gehört, glaube ich, auch eine neue Episode vom Django Chat Podcast, wo Peter Baumgartner von Linkel Roop, der auch dieses High-Performance-Django-Buch, der hat das, glaube ich, geschrieben.

Und der hat auch so ein Ding gebaut.

Achso, ich meine, Heroku ist ja auch immer so die Empfehlung für, wenn man sich keine Gedanken machen möchte, aber Heroku ist halt auch echt.

Und viel Geld ist halt recht teuer.

Und es ist halt auch so, dass deren, ja, so ist es doch eher so ein Ruby und Rails-Ding und deren Django-Support erfährt jetzt nicht immer unbedingt die Liebe, die man jetzt sich erhoffen würde, vielleicht von so einem Hoster.

Und um es mal so vorsichtig zu formulieren.

Und der hat halt halt jetzt auch sowas gebaut, nämlich, das nennt sich Uppack.io und ist halt auch im Grunde sowas wie Heroku, also sozusagen, du kannst deinen Kram auf AWS hosten, nur halt mehr so auf Django optimiert und so.

Aber cool, ja, es ist schön zu sehen, dass es da mehr Optionen gibt.

Das ist eigentlich wunderschön.

Es ist spannend, dass es so viele Firmen im Indischen Ozean gibt.

Das ist schon sehr cool.

I.O.

ist indische Ozean.

Achso.

Ja, hat der indische Ozean mal ausnahmsweise mal was richtig gemacht mit der Wahl des Top-Level-Main-Hounts.

Naja, Glück gehabt.

Glück gehabt.

Ja.

Pack-I.O.

sagst du.

Du abtürstest den Link ja sicherlich.

Genau, ab Pack mit 3P.

Das ist ein bisschen schlecht vielleicht, ich weiß nicht genau.

Naja, aber genau, ich tue den Link in die Shownotes, kann man sich das angucken.

Ja.

Jetzt haben wir nur noch Reste übrig, oder?

Ja, jetzt haben wir nur noch Rest übrig.

Es ist nur der Rest.

Da müssen wir jetzt über die Reste reden.

Also, wo waren wir eben stehen geblieben, Johannes?

Representation ist Technik.

Als im Vergleich zu Remote Procedure Call.

Weil, also ich meine, Remote Procedure Call, das ist so die Technologie, die man kennt und das ist so ein bisschen so die Sache, die man halt machen möchte, wenn man sagt, okay, ich habe jetzt hier ein Programm geschrieben und das ist lokal, aber es wäre doch viel cooler, wenn das irgendwo anders laufen würde.

Und dann macht man sich halt irgendwie so einen Endpoint, wie auch immer, der geartet ist, ja.

Mit einem Java XML, RPC.

Klein, das ist das Erste, was mir jetzt in den Gedanken kommt.

Ja, das hatten wir, aber sprich es ruhig aus, wie es früher war.

Da Soap zum Beispiel oder so.

Ja, das hat man

früher einfach so gemacht.

Und das ist dann im Wesentlichen halt eine Java-Bibliothek, die man sich einbindet, die Funktionen anbietet, die aber nicht lokal ausgeführt werden, sondern remote.

Und das können alle möglichen Funktionen sein.

Die können was berechnen oder die können eine Datenbank abrufen oder die können, was weiß ich, einen Roboter starten oder die können die Kamera oder keine Ahnung, irgendwas können die machen, ja.

Und das siehst du denen aber erstmal nicht an, weil die eben so gepackt sind.

Eben gerade diese Java XML-LPC, die macht dann eine Java-Klasse.

Und wenn ich da alle Verbindungsdaten reingegeben habe, richtig, und mich korrekt verbunden habe, dann funktioniert die wie eine lokale Funktion.

Und das ist ja auch so ein bisschen das, was im Namen steckt.

Remote Procedure Call heißt einfach, es gibt normale Funktionen, also normale Prozeduren und es gibt Prozeduren, die sind auf einem anderen Rechner.

Und das ist das, was man früher gemacht hatte.

Und es war ganz, ganz schlimm.

Das war ganz, ganz schrecklich.

Warum?

Weil es hat nicht funktioniert und man wusste nie, was dann das Ergebnis ist und wie lange das dauert.

Und man hatte quasi gar keine Garantien über gar nichts.

Und diese Interfaces bauen war auch ganz schrecklich.

Da musste man dann so eine Webservice.xml haben und die hat auch nur die Hälfte der Zeit funktioniert und dann gab es Versionierung, ja.

Wenn dann nicht die richtige Version von dieser API lief, dann und und also es gibt ganz viele Stellen, an denen das einfach zerbricht.

Soap ist prinzipiell eine sehr coole Idee, aber praktisch habe ich nie erlebt, dass es angenehm gewesen wäre oder zuverlässig.

Und ich denke, also ich weiß es natürlich nicht, ja, ich war nicht dabei, aber ich denke, dass das eben der Grund war, warum man zu REST APIs, oder einer der Gründe, warum man zu REST APIs gegangen ist, wo es eben nicht darum geht, Prozeduren aufzurufen.

Also wo man nicht sagt, mach irgendwas, sondern wo man im Endeffekt nur sagt, entweder gib mir ein Objekt oder nimm dieses Objekt.

Könnte man ja vielleicht auch so formulieren, dass man sagt, man versucht einfach die Dinge, die im HTTP-Protokoll eingebaut sind, auch tatsächlich zu benutzen, so wie sie halt schon da sind und nicht, weil das ist halt eigentlich, glaube ich, auch der Vorwurf sozusagen von Restseite, die man an so Sachen wie Saub oder auch Sachen, wo dann andere Leute versucht haben, Korba irgendwie zu retten in der neue Webwelt, macht, dass man sagt, ja, ihr habt ja so ein altes, überholtes Architekturmodell, von dem, wie eure verteilte Anwendung funktionieren soll.

Und das versucht ihr jetzt, jetzt versucht ihr das Web dazu zu degradieren, dass das nur ein Transportlayer ist für eure Idee, die auch schon vorher eigentlich nicht funktioniert hat.

Was für ein Korba?

Die Webpage?

Was war's das?

Da gibt es eine schöne Organisation mit dem Kürzel OMG.

Oh mein Gott.

Common Object Request Broker Architecture.

Ja, genau, und die hat sich das, die hat das standardisiert.

Das ist die Object Management Group.

Und genau, ich hatte auch, ich hatte viel Spaß mit Koba schon.

Und ja, das war das war auch alles nicht schön.

Das klang alles nach einer guten Idee.

Und dann hat man es versucht zu verwenden und dann sind schreckliche Dinge passiert.

Ich meine, vielleicht haben Leute das auch verwendet und es war voll cool, aber ich erinnere mich dann große Schmerzen.

Okay, und in HTTP selbst ist dann sowas eingebaut wie gib mir ein Objekt oder bekomme ein Objekt.

Genau, HTTP selbst hat ja erstmal nicht so viele verschiedene Dinge, die es garantiert, aber es garantiert im Wesentlichen einen Pfad und ein Verb.

Und diese Verben sind sehr streng limitiert.

Also prinzipiell kann man da jedes Verb mitschicken, aber der Standard hat nur so eine Handvall.

Und da gibt es insbesondere Get und Post und Get heißt halt gib mir und Post heißt nimm das.

Es gibt noch ein, zwei andere, die da wichtig sind.

Es gibt noch Put und Delete, die immer wieder notwendig sind.

Ja, aber gerade da fängt es dann schon so an.

Was ist eigentlich der Unterschied zwischen Put, Post und Patch?

So spontan, ich weiß es nicht, ich würde sagen, spontan wäre es so put, da updatest du ein komplettes Objekt und Patch nur ein Teil davon.

Also wenn du sozusagen nur ein Attribut an einem Objekt änderst, dann machst du es per Patch.

Wenn du das Objekt eine Version änderst, dann putest du das komplett.

Und Post?

Post ist hinzufügen.

Ja, aber das ist ja auch nicht so.

Das ist ja bei REST auch nochmal anders geregelt.

Ist ja, wenn du auf eine ID postest, putest, dann ist es ein neues Objekt.

Wenn es die noch nicht gibt, dann ist es Neues.

Und wenn du auf eine.

Ja, so ganz klar ist es.

Okay.

Ja, ehrlich gesagt, weiß ich auch nicht.

Dann braucht man nur noch zwei.

Get und Post.

Ja, das ist halt das, was viele Leute mitmachen.

Mit denen kommt man zurecht.

Mit denen kommt man schon zurecht, aber das ist natürlich.

Delete brauchst du noch, Dominik.

Delete brauchst du auf jeden Fall.

Na gut.

Man kann nicht posten und sagen, dass das Objekt bitte entfernen.

Du kannst, ähm nee, weil du kannst auch, du kannst posten.

Das kommt jetzt drauf an.

Und da fangen schon so ein bisschen die Probleme bei REST an.

REST besteht ja aus mehreren Teilen und ein Teil ist eben, benutze nur diese HTTP-Verben.

Und da fängt eben das eins der Probleme schon an.

Eine der Konventionen ist, wenn du auf den Pfad eines Objektes postest und nur eine gewisse Menge von Attributen mitgibst, dann heißt es, ändere bitte diese Attribute.

Wenn du jetzt sagen würdest, wenn ich darauf poste, ohne ein Attribut zu geben, dann hat es schon zwei Bedeutungen.

Hat es entweder die Bedeutung, die du jetzt sagst, nämlich lösche dieses Objekt, also entferne alle Attribute, oder es hat die Bedeutung, ändere keinen Attribut.

Und weil das nicht offensichtlich ist, ist es einfacher, Delete zu nehmen.

Delete ist eindeutig.

Und Delete ist auch, Delete ist eine von den Sachen bei REST, die völlig unstrittig sind, ja.

Wenn ich eine URL habe, wenn ich einen Pfad habe, die hat zu einem Objekt gehört und ich mache da Delete drauf und ich darf das und da kommt der richtige Status zurück, dann ist es gelöscht.

Das ist völlig unstrittig.

Und das ist auch eine super Sache, weil ab jetzt brauche ich mir ums Löschen von Objekten keine Sorgen mehr machen.

Das ist jetzt geregelt.

Das geht immer.

Was dafür sprechen würde, dass man Post nicht löscht.

Nein, eigentlich nicht.

Genau, mit Post löscht du nie.

Post ist immer nur, Post und Put und Patch sind immer nur additiv.

Okay, also, aber okay, den Unterschied da genau zu verwenden, ist wahrscheinlich, wie man gerade schon rausgehört hat, eher vielleicht gar nicht so viel zu tun.

Ja, man findet auch ganz viel tatsächlich in freier Wildbahn dann halt Leute, die irgendwie das halt anders machen, als man das vielleicht tun sollte.

Ja, und

wir werden sich jetzt auch hier ganz viele Kommentare kriegen, dass wir alle Idioten sind und dass es nur eine wahre Lösung gibt.

Ja, der kommt dann.

Nee, 201 kommt dann zurück.

201 heißt Objekt erzeugt.

Ja, und ich meine, ich sehe immer, wenn ich irgendwie, also es gibt, wenn ich mit anderen Apis rede, ist es ganz oft, dass ich irgendwie was erzeuge und dann kommt halt 200 zurück zum Beispiel, ne?

Was halt falsch ist oder so.

Ja, aber kann auch sein.

Nee, kann auch sein.

API nicht reingekraft.

Weil 200 bedeutet ja nur okay.

200 bedeutet ja nur in Ordnung.

Und es kann ja tatsächlich sein, und ich halte das tatsächlich für sinnvoll, 200 zurückzugeben in vielen Fällen und nicht 201, weil das Objekt, was erzeugt wurde, ja erstens andere Attribute haben kann, die du nicht mit erzeugt hast, zum Beispiel seine eigene Identität oder Verweise auf irgendwas oder Counts von irgendwas.

Und zum anderen kann es ja auch sein, dass du, dass nicht alle Attribute angenommen wurden, die du geschickt hast.

Weil sie halt falsch waren oder weil sie, keine Ahnung, weil du nicht die Berechtigung hast oder sowas.

Ja, aber nicht Berechtigung, sondern wieder was anderes.

Aber gut.

Nee, weil

du, weil du, ja, okay, weil sie halt verworfen wurden.

Und dann ist es absolut richtig, meiner Meinung nach, mit 200 das erzeugte Objekt zurückzugeben.

Tja, das kommt ja normalerweise auch beim 201 kommt ja auch das erzeugte Objekt zurück.

Nee, 201 hat keinen Inhalt.

Nein?

Nee, 201 hat normalerweise sollte keinen Inhalt haben.

Ah, okay, okay, okay.

Gut, ja.

Also es ist.

Auch das ist so ein Problem.

Auch das ist so ein Problem, wenn man auf 201 wartet und erwartet, dass das Objekt zurückgegeben wird, dann kommt ganz oft gar nichts zurück und dann schlägt quasi diese Abfrage fehl, weil du, weil kein Content kommt.

Auch damit habe ich mich schon abgeplagt.

Ja, ja.

Na gut, also.

Ich plag mich immer mit dem 4.02 ab.

Was war das nochmal?

Payment required.

Payment required, ja.

Reserve for Future Reviews.

Nee, der wichtigste ist doch 418.

Ja, T-Pot war das, oder?

Arme T-Pot, ja.

Ja, genau.

Also ich meine, tatsächlich in der Praxis funktioniert es meistens eigentlich ganz gut.

Man kann sich da irgendwie durchwurscheln und dann geht es schon.

Und genau.

Tatsächlich ist aber auch, da gibt es ja so, dann, wie nennt sich das dann immer, Maturity-Level irgendwie, Rest, also hinter diesem ganzen Kram ist ja so ein Konzept.

Irgendwie einer der Leute, die halt ja auch so, so eine der Hauptverantwortlichen hinter dem Web hat, hat das halt, steckt halt auch hinter dieser Rest-Idee.

Rolf Hilding hat er seine Dissertation drüber geschrieben, ja genau, 2005 ist sie, glaube ich, erschienen.

Und da kann man sich angucken, gibt es online, auch als Webseite.

Sehr schön.

Oh, auch sehr interessant.

Link, please.

Ja, genau, Link kommt in den Show Nutz.

Auch sehr interessant, die Dissertation fängt an und endet jeweils mit einem Zitat von, na, wie heißt das noch?

Der Architekt mit den Entwurfsmustern.

Mit den Entwurfsmustern, aber.

Der, der mit den diesen Patterns angefangen hat, genau.

Christopher Alexander, glaube ich.

Und genau.

Naja, also es gibt da interessante Verbindungen.

Und der also in dieser Dissertation beschreibt er halt sozusagen, was so ein bisschen die Idee hinter dem Ganzen ist und dass eigentlich er sich wünscht, dass halt sozusagen, das hat halt etwas komische Abkürzungen.

Dass sozusagen Hypermedia as the engine of State.

Genau.

Moment, wie war das?

Hate to us.

Hate to us, genau.

Application State, genau.

Hypermedia is the Engine of Application State, genau, richtig.

Es ist lang und kompliziert und komisch.

Und was heißt das?

Was ist das?

Was macht das?

Naja.

Das würde ich jetzt auch gerne mal wissen.

Wenn man das wirklich genau wissen will, sollte man sich nochmal diese Disession.

Also tatsächlich finde ich das beste Beispiel dafür, wie das funktionieren kann, ist halt das Web.

Dass man sagt, also da ist das Hypermedia, was man halt sieht, ist das HTML.

Und du kannst da halt dann Links folgen.

Und siehst dann halt neue Sachen, neue Webseiten und so und kannst dann Dinge machen und sozusagen, wie deine Applikation, also deine Webseite, aussieht, bestimmt das Hypermedia hat da drin.

Das ist jetzt aber nicht so, wie die meisten Leute Rest-Schnittstellen verwenden, sondern die meisten verwenden das halt zum Beispiel, jetzt weiß ich nicht, was halt viele machen, als Datenlieferant für ihre Singlepage-App.

Aber die Singlepage-Apps, die es so gibt, die sind eigentlich so gar nicht Rest.

Und die sind auch, was das Hyper-Media-Ding angeht, eigentlich ist das auch wieder so ein Ding, was sich aus einer alten Welt rübergerettet hat.

Insofern, ich bin mal gespannt, wie es ausgeht.

Es kann ja auch sein, dass sich das dann durchsetzt.

Aber tatsächlich, also ich finde ein wichtiger Punkt, so bei dem, diese Single Page-App ist eigentlich voll cool und so, man kann damit tatsächlich ja Applikationen bauen, die so ein bisschen wirken, als wären sie Desktop-Applikationen so wie früher.

Aber wenn man sich jetzt vorstellt, man will ein Web draus bauen und jetzt hinter jedem Link liegt so eine Single Page-App, wo erstmal ein paar MB Zeug kommen, dann ist das ja eigentlich gar nicht so gut.

Also, das Stau, Stau, Stau auf der Datenautobahn.

Das macht das Web halt irgendwie kaputt.

Das macht es halt, es ist halt nicht so, also so eine Single Page-App, ich meine, Single Page-App ist eigentlich auch ein falscher Name, aber so diese JavaScript-Applikationen, die halt nur RPC quasi zu einem Server machen, die sind halt eine in sich abgeschlossene Applikation.

Und wenn man da, wenn alle Webseiten nur noch so etwas wäre, dann würden Links

sehr viel Arbeit macht, meinst du?

Weil gute SPAs haben natürlich.

Ja, ja klar, Server-Side-Rendering und

wie den internen Zustand, wo du auch Deep Links machen kannst auf SPAs.

Weil das ist nicht so gängig, um es mal so zu sagen.

Ja, aber was ist jetzt ein Deep Link wieder?

Ja, wenn

du so eine SPA aufrufst, dann bist du ja, jetzt sagen wir mal auf, keine Ahnung, spa.io, ja.

Und dann gehst du da in deine Daten rein und in die Tabelle und dann gehst du da in Zelle A17.

Und ein Deep Link wäre, wenn es eine Möglichkeit gäbe, eine URL anzugeben, die auf diese Zelle verweist.

Damit du deinem Kollegen sagen kannst, hier, schau dir mal diese Zelle an.

Und ganz viele SPAs machen das aber nicht.

Du kannst nicht sozusagen dahin navigieren und dann aus der Adresszeile den Link rauskopieren.

Weil du immer noch bei spa.io bist und sonst nirgends, weil der Zustand, den du erreicht hast, nur innerhalb der Anwendung ist und nicht in eben diesem Hypertext.

Das heißt, du kannst da nicht darauf verlinken.

Und das ist genau das, was sozusagen das Problem an dieser Stelle ist, du kannst nicht darauf verlinken.

Du kannst nicht sagen, das hier und jeder, der es abruft, sieht es dann, wenn er es sehen darf.

Immer modulo dieser Berechtigungen und der Sichtbarkeit und so weiter.

Und das ist ja aber eigentlich eine Sache, die in REST APIs schon so drin sein sollte, ja, dass du zum einen Links machen kannst auf Objekte, also API slash Spreadsheet slash Spreadsheet ID slash table slash cell A slash row 17, irgendwie sowas, ja, solltest du prinzipiell machen können.

Und auch innerhalb dieser API solltest du eigentlich nie irgendwie nur IDs angeben.

Das ist jetzt dann hier, da ist der Inhalt 23 drin, sondern eigentlich solltest du angeben, da ist der Inhalt drin, der unter folgender URL erreichbar ist.

Und wenn man das sauber macht, dann ist das eine ganz, ganz mächtige Sache.

Ich versuche das bei meinen APIs immer zu machen, weil das die Entwicklung mit der API wesentlich vereinfacht, weil ich eben nicht wissen muss, was das bedeutet, wenn da drin steht ID 17, sondern ich muss nur einen Link aufrufen können.

Und einen Link aufrufen, das kann ich.

Das geht, genau.

Und dann kriegst du das Objekt und weißt, was da drin ist.

Genau.

Und dann kannst du auch weitergucken.

Ja, aber tatsächlich eben, genau, und das ist halt so der Unterschied, wenn man jetzt RPC machen würde oder so, wenn du jetzt da irgendein Objekt kriegst mit bestimmten Parametern oder so, da kannst du halt auch nicht drauf verlinken.

Das ist halt schon, genau, das ist halt irgendwie so eine der wesentlichen Geschichten, wobei man halt auch sagen muss, also die Idee ist nett und das Web funktioniert ja auch so, aber tatsächlich alle anderen Beispiele, die ich gehört habe, oder die versuchen, Leute dann zu konstruieren für, wo das noch eine gute Idee wäre, die sind alle ziemlich konstruiert.

Also in diesem Web-Fall hat es einmal geklappt.

Aber ansonsten, also irgendwelche Applikationen, die ihr UI dadurch aufbauen, dass sie irgendwie aus einer API irgendwie ihre Formulare bekommen und das, wo sie, wo sie so.

Ja, das hört sich ja grauenhaft an.

Genau.

Das hört sich schon ziemlich grauenhaft an, ja.

Das klingt so ein bisschen nach SAP, irgendwie alle Sachen sehen irgendwie gleich aus und so.

Also alles zur Laufzeit wird es zusammengebaut.

Ja, also ich meine, es wäre natürlich schön, also der Vorteil, den du halt hast, wenn du das so machst, ist halt, dass auch ältere Browser funktionieren können.

Du musst halt nicht immer irgendwie den Client austauschen und gerade wenn du jetzt App Stores hast oder so, wäre es natürlich auch nett, wenn du, wenn Leute mit alten Client-Anwendungen halt auch deine neue Geschichten benutzen können und du sozusagen mal so ein bisschen Progressive Enhancement machst und die neuen Geräte können dann halt den neuen Kram machen und die alten sehen aber immer noch die alte Seite sozusagen.

Tatsächlich glaube ich aber, dass das praktisch niemand so macht.

Das ist ja auch ungeheuer schwierig, das zu machen, weil die Interner verändern sich ja auch.

Also ich meine, wir könnten auch gerne mal noch ein Stündchen über API-Versionierung sprechen, weil auch API von uns eine Meinung dazu.

Und ich weiß auch mindestens drei verschiedene Wege, wie man das machen kann.

Aber ja, ich kenne quasi keinen Fall, wo es sich lohnen würde, verschiedene API-Versionen gleichzeitig laufen zu haben, was ja sehr teuer ist erstmal.

Und deshalb, das mag ein heroisches Ideal sein, aber es ist vielleicht schwierig, das in der echten Welt.

Na gut, du müsstest.

Nein, nein, nein.

Also du müsstest nicht unbedingt unterschiedliche API Versionen, sondern du würdest es halt so machen wie bei HTML auch.

Du würdest halt sagen, okay, hier ist halt ein Attribut und da steht halt an dem Attribut noch dran, weil wenn du das in JSON machst, nicht in HTML, so ab hier nur für Clients, aber mit der Version oder so, keine Ahnung.

Die anderen müssen ja gar nicht gucken, die können das nicht.

Ja, okay, aber dann hast du ja unterschiedliche API-Versionen, die halt additiv sind.

Ja, aber du würdest auch dem alten Client das Neue ausliefern und der würde das dann einfach ignorieren, wenn er sagt, oh, das ist für mich nicht interessant.

Also wie bei HTML ist es ja auch so, genau, wenn du ein neues Tag hast, die Browser ignorieren das einfach, die es nicht können.

Ja, oder auch Header generell.

Das ist generell eine gute Idee, so additive, nur die Sachen verarbeiten, die man versteht.

Also nicht generell, aber in vielen Fällen ist das eine gute Idee.

Weil man dann eben diese automatische Backwards-Compatibility hat oder automatische Forwards-Compatibility, je nachdem, wie man das sehen möchte.

Ja.

Also irgendwie, also das ist die Idee, ist irgendwie voll cool, aber ehrlich gesagt, ich weiß nicht so richtig.

Ich bin mal gespannt.

Also bei dem bei jetzt HTML und Web hat es ja eigentlich mal geklappt, aber ob das, äh, wie sich das so in Zukunft entwickelt, keine Ahnung.

Ja, und andere Dinge sozusagen sind auch nicht mehr so richtig gut gealtert, fürchte ich.

Also sowas wie zum Beispiel, also eigentlich sind das sind schon nette Ideen.

Also das HTTP-Stateless ist ja eigentlich cool, das hat diverse coole Vorteile.

Dass GET halt immer nur irgendwas an Daten liefert und nichts ändert, ist auch super cool, weil das bedeutet halt, du kannst super cachen.

Ja.

Und kannst da auch so oft machen, wie

du willst.

Kannst du oft machen, wie du willst, voll gut.

Das Problem ist nur, so inzwischen ist es halt TLS, HTTPS ist halt überall.

Sollte man auch nicht mehr ohne machen.

Ja.

Ja, genau.

Und damit wird das mit der Cachbarkeit und so, das ist halt dann alles so ein bisschen für die Tonne, weil, ja gut, der Browser selber kann es auch cachen, aber so, dass da irgendwo.

Der Software kann es cachen.

Der Software kann es cachen, der Clean kann es cachen, aber dazwischen kannst du nichts.

Und ja, damit hat das nicht mehr so eine riesig große Relevanz.

Und das war ja auch im, ja das sieht man jetzt auch heute ja, die ganzen, so ja, Phoenix Live View, bei Rupert und Mails gibt es das, ne, mit Stimulus und diese ganzen Hotwire-Geschichten in anderen Frameworks kommt das jetzt auch irgendwie, dass man wieder HTML über Websockets schickt oder so.

Und einer der Gründe, warum man das anfängt zu machen oder so, ist halt auch, dass es einfach, wenn man sich anguckt, was auf der Leitung passiert, der totale Wahnsinn ist.

Weil es eben, weil HTTP stateless ist, muss da halt immer irgendwie alles mitgeschickt werden, weil, naja, ist ja stateless.

Ja, klar, weißt du nicht, was der schon hat, oder nicht.

Genau.

Und das ist eigentlich total ineffizient, auch ehrlich gesagt.

Und deswegen gehen halt dann viele Richtungen, naja, nehmen wir doch einfach Websockets oder so, da haben wir dann, das ist halt dann nicht mehr status.

Ja, das ist aber auch so eine der, jetzt sind wir schon so weit, dass wir über die Nachteile von REST-APIs sprechen.

Dass diese Objekte so ein bisschen in sich geschlossen sind und auch nicht auf den Anwendungsfall eingehen können.

Das ist ja eine der Vorteile von RPC, ja, dass du halt sagst, ich möchte, dass folgende Operation passiert und dafür sind die folgenden drei Werte notwendig und dann kriegst du eben die Ergebnisse der Operationen, das sind dann genau sieben Werte oder irgendwie sowas.

Oder genau dieses Objekt und genau dieses Objekt.

Und das hast du jetzt mit REST ja nicht mehr so einfach.

Mit REST greifst du dir immer quasi auf ganze Ressourcen zu.

Oder eben auf Teilressourcen, die dann vom Server auf eine gewisse Art und Weise zur Verfügung gestellt werden, die aber eventuell gar nichts mit deinem Use Case zu tun haben.

Also wenn ich jetzt meine gesamte Freundesliste abrufen möchte, dann müsste ich prinzipiell alle Links zu meinen Freundesobjekten abrufen und dann allen Links folgen und jedes Freundesobjekt einzeln abrufen.

Damit ich meine Freundesliste anzeigen kann.

Was ja absurd ist, weil meine Freundesliste ist ja einfach nur eine Liste von den Namen der Freunde und fertig.

Ja, ja.

Ja, und man würde sich dann halt vielleicht wünschen, eben, auch gerade wenn man dann jetzt unterschiedliche Clients hat, die unterschiedliche Sachen darstellen, dass man als Client kontrollieren kann, was denn dann da kommt und das je nachdem, was man halt braucht, ja, aber dann hat man im Grunde hat man dann eben keine Restschnittstelle, sondern hält man irgendwie sowas wie eine Datenbankschnittstelle.

Ja, genau, und das ist ja auch der Grund, warum es diese Weiterentwicklungen gibt, die du jetzt gleich erklärst.

Genau, wo der Client eben, wo der Client eben kontrollieren kann, welche Attribute geschickt werden und welche Objekte geschickt werden.

Weil es eben Use Cases gibt, in denen nicht das ganze Objekt interessant ist und oder sehr viele verschiedene Objekte interessant sind.

Ja.

Nur dann würde, also aus der Sicht eines Restpuristen würde ich jetzt sagen, ja gut, aber das ist ja, da macht der Client ja schon viel zu viel.

Das hat den Client alles nichts anzugehen, das muss alles der Server machen.

Das ist ja nicht, da hat der Client viel zu viel State und für ein weiß, der ist ja, ja, und das geht ja alles gar nicht.

Ja, aber das ist ja, also ich meine, das

gegen Regen argumentieren.

Es ist schlecht,

dass es den gibt und der fällt aus dem Himmel runter und der macht alles nass, aber es ist halt so.

Ja.

Das gibt halt, also ich meine, es ist nicht schwer, sich vorzustellen, dass es Leute gibt, die ihren Freunden Nachrichten schicken wollen.

Und schon brauche ich eine Liste der Leute, denen ich Nachrichten schicken kann.

Und da hilft mir aller Rest Purismus nichts, weil das muss dann irgendwie abdecken.

Es gibt auch Fälle, sagen wir mal so, um es positiv zu formulieren, für manche Anwendungsfälle muss man sich braucht es ein bisschen Umdenken von diesem Prozeduralenken.

Wir als Programmierer haben ja oft so ein prozedurales Denken.

Ich möchte, dass jetzt irgendwas passiert und deshalb schreibe ich diese, rufe ich diese Funktion auf.

In Python ist ja im Wesentlichen alles, was man macht, irgendwelche Funktionen aufrufen und innerhalb der Funktionen passiert dann irgendwas anderes.

Und das ist jetzt bei REST ganz anders.

Bei REST sage ich ja einfach nur, es soll dieses Objekt geben.

Mehr kann ich ja nicht sagen.

Und wenn ich jetzt eben möchte, dass was passiert, zum Beispiel, dass eine Nachricht geschickt wird, dann sage ich nicht, schicke diese Nachricht an.

Sondern es soll eine Nachricht geben, die an deren Empfänger folgende Empfänger ist und deren Text folgende Text ist und deren Absendedatum gerade jetzt ist.

Und das erfordert ein gewisses Umdenken, wenn es eben was inhärent Aktives ist, was passiert.

Bei Nachrichten schicken ist es schon, könnte ich schon mal sagen, könnte man schon sagen, okay, das ist jetzt nicht was, was passiert, sondern es ist halt ein Eintrag in der Datenbank und ich sage, füge dieses Nachrichtenobjekt hinzu.

Aber wenn das irgendwas ist, was was steuert, ja, wenn ich eine Schnittstelle habe für irgendwelche Geräte oder für irgendwelche Prozesse, dann finde ich das schon schwieriger, zu sagen, es soll jetzt dieses Objekt geben.

Ja, ja.

Wenn ich ein Licht anmache über eine Rescue-Stelle, dann heißt es, ich bearbeite das Lichtaktivierungsobjekt und setze das Attribut an auf, ja, anstatt dass sie sagt, mach das Licht an.

Ja.

Ja, ja, das ist so ein bisschen, ja.

Es erfordert ein gewisses Umdenken.

Ja.

Ja, ja, ja, ja.

Ja, ich überlege gerade, ob man sagen könnte, man erzeugt einfach ein Event oder so, dann, aber.

Ja, das ist ja dann auch das, was man sich dann macht.

Ein Kontrollvorgang steht Licht an oder Licht aus.

Ja, genau, wo du dann eben sagst, wo man sich so ein bisschen behilft, wo man sich sagt, ich erzeuge jetzt nicht, ich verändere jetzt nicht das Lichtzustandobjekt, sondern ich erzeuge ein Lichtanschalten-Wunschobjekt oder irgendwie sowas, ja, dass du sozusagen Funktionen als Objekte siehst und dann eben ein neues Funktionsobjekt erzeugst.

Aber das ist ja schon ein bisschen beschummelt, oder, Jochen?

Fühlst du dich da gut dabei, wenn du sowas machst?

Nee, auf der anderen Seite würde ich sagen, ich meine, worauf es hinausläuft, die grundsätzlichen Operationen, die man tun kann, sind halt, ja, das ist mal, ich weiß nicht, das hatten wir bestimmt auch schon mal ein paar Mal erwähnt oder so, ist halt CRUD.

So, Create, Read, Update, Delete.

Und ich finde es immer wieder erstaunlich, was sich alles darauf mappen lässt, weil tatsächlich.

Ja, alles, du kannst alles darauf mappen.

Ja, ja, gut, aber alles, was in dem Computer drin ist, kannst du ja darauf mappen.

Es geht sogar halbwegs elegant.

Also oft ist es tatsächlich so, dass es auf den tatsächlichen Anwendungsfall eigentlich ganz gut ist.

Also oft passt es einfach ganz gut.

Und man ist eigentlich dann zufrieden.

Dann natürlich, in manchen Spezialfällen muss man halt dann überlegen und tricksen, weil es dann so nicht einfach geht.

Aber prinzipiell, ja, das ist auch immer etwas, was man dann.

Es gibt schon so Sachen, Jochen, wo ich mir da sehr schwer tue.

Wo eben was passieren soll, wo mein gedankliches Modell nicht ist, da wird ein Datensatz erzeugt oder bearbeitet, sondern da soll jetzt etwas passieren.

Da soll jetzt ein.

Ich schicke ein Bild an eine Bilderkennungs-API.

Dann ist es für mich nicht, ich möchte, dass es dieses Bilderkennungsobjekt gibt, sondern dann sage ich im Wesentlichen, ich möchte, dass jetzt dieses Bild ausgeführt wird.

Ich möchte, dass jetzt mit diesem Bild irgendwas ausgeführt wird.

Und trotz allem, es gibt ja die vorgenannten Puristen, die sagen, alles muss eine Rest-Schnittstelle sein und du musst alles 100% Restv machen.

Und die dann auch so eine Schnittstelle eben als Restschnittstelle machen würden, die mir auch meine Schnittstellen oftmals um die Ohren hauen würden, weil ich eben so prozedurale Endpunkte habe, so prozedurale ein Funktionsobjekt mit folgenden Parametern wurde angelegt.

Ja, das ist natürlich irgendwie.

Also ja, nee, also ich meine, es gibt Dinge, die da nicht so gut reinpassen, wo man dann auch.

Ich meine, gerade weil sowas wie, wenn man Splobs hat, eben Bilder oder sowas, da ist es sowieso schwierig, da irgendwie, genau.

Ist ja auch dann ganz schwierig, das kriegst ja auch nicht per Get so, also das natürlich.

Du kriegst auf jeden Fall nicht mehr per JSON.

Du musst dann halt, wenn du Byterange testst auf irgendwelche Blobs machst, dann.

Moment, wenn man Byterange denkt, irgendwelche Blobs, also ein Blob ist irgendwie eine Art Dateiobjekt oder sowas

erstmal ja.

Also zum Beispiel sowas in einem Podcast-Episode.

So eine Podcast-Episode und du willst jetzt an Minute 30 anfangen zu hören, weil da beginnt der interessante Teil über Rest.

Aber das ist ja tatsächlich bei REST nicht vorgegeben, welche Datenstrukturen du verwendest, sondern ganz im Gegenteil.

Naja, stimmt.

Jeder Request soll ja immer einen Media-Type haben und dann halt kannst du es in verschiedenen Sachen abrufen.

Also gar nicht was nur JSON, ne?

Nee, nee, das kann auch von uns anderem.

Kann auch XML sein, wenn du willst.

Hurra!

Nee, nee, aber das ist ja eine der Eigenschaften vom Web, dass das Web eben nicht nur JSON übertragen kann, sondern es kann alles übertragen.

Und das soll hier eben auch mit reingehen.

Und das ist auch eine der großen Stärken, die zum Beispiel in Django hat man ja diese wunderbare Bibliothek Django Rest Framework.

Ich erinnere mich noch, als ich die zum ersten Mal gefunden habe und es war so eine Offenbarung, dass sowas geht und dann so schöne Schnittstellen macht.

Und die einen ganz einfachen Trick verwenden.

Browser senden als Media Type oder als Preferred Media-Type immer Application HTML mit.

Und so Schnittstellen haben ja normalerweise Application JSON.

Und wenn du aber Application HTML abrufst von dieser mit Django Rest Framework erzeugten Schnittstelle, dann kriegst du das Ergebnis als Webseite.

Mit allen Bells und Whistles, die es so gibt.

Also mit Formularen und mit Login-Anzeige und mit Dokumentation automatisch angezeigt.

Und das ist eine super Sache, ja.

Du kannst verschiedene Media-Types anfordern.

Und auch Django Rest Framework stellt ja durch diese Serializer, die man normalerweise hat.

Das ist wie das Formular, was man sonst so kennt, ja.

Genau, der stellt dieses Formular zur Verfügung, der stellt auch den JSON-Datentyp zur Verfügung, der gibt dir, also es gibt auch die Möglichkeit, da XML einzustellen.

Dann kriegst du halt XML-Objekte, die auf irgendeine Art und Weise formatiert sind.

Du kannst auch selber einen schreiben, der halt irgendwas anderes macht.

Und das ist auch eine der Stärken.

Das bedeutet ja aber nicht, dass jede Antwort auf Get immer ein JSON sein muss.

Das bedeutet halt nur, dass es Media-Types gibt, die von verschiedenen Branches unterstützt werden und andere werden halt nicht unterstützt.

Und gerade bei so einem Blow-Projekt wäre es halt dann Application.

Irgendwie ein binärer Stream.

Weiß ich nicht.

Octet-Stream, ja.

Ja, ja, ja.

Nee, stimmt schon.

Also insofern würde das da auch reinpassen.

Also ganz kurz nochmal, OctetStream, was ist das denn?

Ja, Octet ist ein cooler, ist der coolere Name für Bayte.

Also es sind einfach Binärdaten, die übertragen werden.

Also zwei hoch.

Nee, das ist so der Fallback-Type.

Für, wenn ich nicht weiß, was es ist, dann sind es halt irgendwie Binärdaten.

Und das heißt halt als MIME-Typ oder als Datentyp heißt es application slash octet-Stream.

Heißt einfach nur irgendwelche Daten, keine Ahnung.

Okay, Octet-Stream.

Auch gerade wieder zum ersten Mal drüber gestolpert, das ist der Wahnsinn.

Wie lange machen wir das eigentlich hier schon?

Ich weiß nicht.

Zu lange.

Zu lange.

Also ja, okay, Dummy REST-Framework haben wir jetzt gerade, dann sind wir ja schon wieder bei Python angekommen.

Wir hatten aber die Methoden gerade alle so einmal durch.

Hatten wir alle?

Also Options gibt es, glaube ich, noch.

Was ist das denn?

Gibt es das?

Auch Rest?

Options ist we get nur ohne Inhalt.

Das ist nur, wenn man sozusagen die Header abrufen möchte, um zum Beispiel den Datentypen rauszufinden oder die verfügbaren Datentypen rauszufinden.

Ja, das heißt, man kann quasi nach Options fragen, dann bekommt man alle Optionen, die Datentypen.

Genau, das ist so wie ein Get.

Das ist genauso wie ein Get, nur dass der den Inhalt nicht mitschickt.

Das wäre zum Beispiel, wenn der Jochen jetzt seine Podcast-Episode abrufen möchte und weiß, dass das eine Zwei-Stunden-Episode ist, also eine von den kurzen, dann.

Geradezu mickrig kurzen.

Meine Frau hat sich vorhin darüber lustig gemacht, dass wir eben so lange Episode aufnehmen.

Aber ich habe gesagt, das ist halt so.

Dann möchte ich eben nicht sofort

die gesamte,

möchte ich nicht diese ganze Episode auf einmal abrufen, sondern ich möchte erstmal sehen, ob ich die überhaupt verwenden kann.

Und dann schicke ich da einen Options-Request hin und dann sagt mir der Server halt, ja, der hat so und so viele Bytes und der Content-Type ist so und so.

Und dann kann ich sozusagen ausprobieren, ob diese Anfrage sinnvoll ist.

Ja, okay.

Interessant.

Aber um jetzt wieder zu APIs und REST-APies zurückzukommen in Python.

Also Django REST-Framework haben wir gerade erwähnt, also da wir alle gerne Django machen, ist das, glaube ich, einer der Ways to go.

Das ist tatsächlich auch ziemlich großartig mit da, habe ich auch viel.

Das ist auch so ein Ding.

Ich weiß nicht, ich glaube, das ist auch so ein wiederkehrendes Thema, das habe ich jetzt auch von anderen schon gehört.

Und das war bei mir so und vielleicht auch bei anderen noch.

Also oft sind so die ersten gut funktionierenden Projekte irgendwas mit Jungle Rest Framework bei vielen Leuten gewesen.

Ich weiß nicht so genau, woran das liegt.

Aber tatsächlich würde ich jetzt mal so, okay, keine Ahnung, also ich habe ja Wirtschaft.

Markt daran liegen, dass es super ist, aber auch, dass es halt einfach, dass man da dann anfängt, in einem etwas interessanteren Markt zu sein, weil das, ähm, was man sonst so sieht, also wenn du irgendwie, keine Ahnung, also das, was halt so, gibt es ja viele, viele, die so WordPress-Seiten machen oder so, keine Ahnung, Zeugs.

Und da bist du halt in einem sehr unglücklichen Quadranten aus meiner Perspektive.

Es ist halt irgendwie Low Budget, ja.

Die Kunden sind üblicherweise nicht bereit, da so wahnsinnig viel Geld auszugeben, weil es gibt so Wahnsinn.

Früher ein besserer Markt.

Ja, kann auch sein, dass das mal gut war, aber ich glaube, mittlerweile ist es nicht mehr so richtig toll.

Dann ist es auch Low Value, weil irgendwie einfach nicht so geil.

Also es sind meistens irgendwelche, naja, doch eher so technisch herausgefordert.

Kommt dann über die Hoster.

Kommt dann über die Add-ons, glaube ich.

Wenn du dann noch ein Magento drin machen kannst, dann bist du wieder.

Genau, da kannst du natürlich irgendwie so lange Plugins installieren, bis es dann vielleicht doch funktioniert.

Das Problem dabei ist, dann bist du aber auch bei einem anderen unangenehmen Attribut, nämlich ist es dann kompliziert und schwierig, das irgendwie richtig hinzukriegen.

Das heißt, es ist schlecht bezahlt, du kriegst nicht so richtig viel Wert hin und es ist auch noch schwierig.

Das ist einfach ein unangenehmer Ort, während, würde ich jetzt mal so sagen, ja.

Während, wenn du halt dann sowas machst wie Jugo Rest Framework oder so, da ist plötzlich irgendwie, da ist richtig Wert drin, wenn da irgendwie die Apps von Leuten richtig gut funktionieren.

Das da suchen Leute händeringend, ja, da sind dann die Preise irgendwie anders und es generiert halt auch irgendwie ordentlich Mehrwert, wenn das halt gut funktioniert und man ein nettes Interface hat, wo man die API irgendwie sich angucken kann und so.

Und ja, das funktioniert dann plötzlich irgendwie, würde ich mal so sagen.

Irgendwie.

Ja, mit Django ist das echt tatsächlich ganz nett.

Also ich habe mal so ein bisschen geguckt, was tatsächlich in der Zukunft noch so geplant ist.

Und da stehen tatsächlich relativ nette Dinge drin.

Zum Beispiel Real-Time-API-Support using WebSockets.

Ja, dann mit Django Channels in Zusammenhang.

Better Authentication by Default, also die wollen vielleicht sogar Dot und Core-Support in das Core-Package reinbringen.

Wo wir ja eben schon kurz sprachen.

Das klingt doch ganz interessant.

Was ist das?

Django Rashmanbock.

Ne, Dominika Zemmer, ich habe gleich noch eine kleine Randnotiz.

Ja, was war denn das?

Genau, was war das für eine Authentifizierung?

JWDT.

Ah.

Java JSON Web Tokens.

Aber da gibt es ja Bibliotheken.

Also ich meine, es ist ja nur ein PIP-installed entfernt.

Ja, aber da gibt es halt verschiedene.

Entschuldigung.

Verschiedene nicht so gute Varianten irgendwie.

Die sind alle so ein bisschen.

Ja, aber das Problem ist halt irgendwie, dass der Standard wohl nicht okay ist und dann ist es halt schwierig.

Die Frage ist, warum der Standard nicht okay ist, wenn ich es richtig verstanden habe, weil es verschiedene Möglichkeiten gibt, diese Schlüssel zu erzeugen oder überall diese Token zu erzeugen.

Weil es wirklich Konfigurationen gibt.

Weil du sozusagen so Downgrade-Angriffe machen kannst.

Du kannst dem Server sagen, ja, schön, dass du diese ganzen sicheren Methoden hast.

Ich bin ein kleiner, dummer Client, ich kann das leider alles nicht.

Ich unterstütze die alle nicht.

Ich unterstütze nur etwas, was halt im Protokoll, was halt im Standard definiert ist, was aber super unsicher ist.

Und dann nutze ich aus, dass es unsicher ist.

Und das ist natürlich kacke, wenn das im Standard steht.

Kannst du machen?

Ja, also das ist halt so.

Du musst dann deinen Server so konfigurieren, dass der die Sachen nicht annimmt, aber es ist relativ schwierig rauszufinden, was jetzt gerade alles schon unsicher ist.

Also das heißt, es geht auch nicht einen Algorithmen, der nehmen kann zum Bereitstellen dieser Token, dass man den nicht zurückrechnen kann.

Ja, zum einen das und zum anderen auch die Token-Art.

Es gibt ja signierte Token und unsignierte Token und wenn der Client halt sagt, ich kann nur die Unsignierten.

Ja.

Und der Server ist so eingestellt, dass er auch die Unsignierten annimmt, dann nimmt er halt auch die Unsignierten.

Und dann irgendwie so einen kleinen Verschlüsselungsalgorithmus nimmt, den man irgendwie in der Rainbow-Table nachgucken kann oder sowas.

Ja, okay.

Ja, oder halt auch gar keinen.

Wenn du sagst, na, naja, Verschlüsselung, naja, kann ich nicht.

Das ist eben wirklich so die Frage, was ist jetzt der gerade der aktuelle Zustand der Sicherheit?

Und eigentlich müsste man sich da sehr gut drum kümmern.

Ja.

Und also ich weiß nur immer, so ganz on detail kann ich es nicht.

Ich weiß nur, dass Leute immer sagen, oh mein Gott, das ist alles schrecklich.

Und JVT, also von im Post auf der Django Mailingliste von James Bennett, glaube ich, wo der mehr oder weniger klipp und klar gesagt, JVT machen wir, werden wir in Django niemals machen.

Das ist irgendwie.

Jot?

Dot?

Was ist das Django?

Ich hab dort.

Dominik, du bist der Einzige der Einzige, der Job sagt.

Okay, ich habe im Blogpost gelesen von Toni, der das schrieb.

Ah, okay.

Ja, vielleicht ist das richtig, ich weiß es nicht.

Ich sage immer Jason Web Turken.

Jason Web Turken.

Ich sage immer Jason Web Turken.

Genau, jedenfalls ist da die Ansage so, nee, das ist das Protokoll ist scheiße, das machen wir nicht.

Was ist denn die Alternative, ja?

Das ist halt die offizielle Alternative, sozusagen jedenfalls, so wie es in dem offiziellen Django-Podcast Django-Chat von Carlton Gibson, einem der offiziellen Django-Antainer.

Der übrigens ein total netter Kerl.

Der ist total netter, ja.

Sometimes pronounced J sagt Wikipedia.

Sometimes pronounced.

Sometimes.

Ich versuche es dann mal jedes dritte Mal zu machen.

Genau, der sagt halt.

Hier im Rheinland sagt man doch JWT.

JWD, JWD.

Egal.

Es ist noch immer Junge oder so.

Es gibt noch so andere Token-Typen auch noch, oder?

Ich vergesse immer wieder.

Paseto zum Beispiel das.

Paseto, genau, danke.

Aber das ist ja genau das gleiche.

Aber du wolltest

gerade immer sicher den Django Tet Talk erzählen.

Genau, genau.

Also da war halt sozusagen die Ansage, na, nimm doch einfach die normale Session Authentication.

Die ist halt so ein bisschen unkomfortabel und so, aber.

Aber auch nicht so arg, ganz ehrlich.

Nicht so arg unkomfortabel.

Ja, aber wenn man doch, also ja, wenn man da irgendwie kann, das, was man in Python dann macht, kann die Dort-Bibliothek nicht einfach sagen, nee, ich bin nicht downgradebar, als ist das nicht da schon mit drin?

Also das muss ja dann.

Standard kann das vielleicht, aber wenn jetzt mein Bibliothek

das verbietet, dann ist das.

Das Problem ist, du weißt ja nicht, mit welchen Clients du redest.

Ja, aber wenn der Client das gar nicht sagen kann, weil meine Bibliothek das gar nicht zulässt.

Ja, dann bist du inkompatibel.

Dann sagen die Clients, mit der API kann ich nicht reden, kaputt.

Ja, gut, kann ja sein.

Aber den Client, den kann ich ja quasi selber sagen, was er

reden soll.

Kannst du ja machen, Dominik.

Kannst du machen.

Dann kann man es mit Job machen.

Dann kann man dabei bleiben, da muss man nicht sagen.

Oh nein.

Ja, aber wenn ich den Client selber ausliefere, also das JavaScript beispielsweise, was dann mit meinem Backend reden soll und ich selber bestimmen kann, was da drin steht, dann kann doch nicht einfach irgendwer sagen, dass er jetzt einen anderen Standard dafür nehmen will.

Dann kannst du aber auch die Session-Authentifizierung nehmen, weil da hast ja nicht viel gewonnen.

Außer, dass du jetzt selber immer die Authentifizierung in jeden Request reintun musst, weil der Browser es nicht automatisch macht.

Ja, und weil ich dann, aber bei Session habe ich ja noch andere Probleme, glaube ich.

Ja.

Ja, ja.

Dann kann ja jemand zu tun, als wer ja meine Session klauen will oder sowas und dann.

Ja, keine Ahnung.

Aber da, ja, das macht der, das verhindert der Browser.

Ja, aber ja, egal.

Es ist kompliziert.

Das mit der Authentifizierung ist auch noch nicht so richtig abschließend.

Ich bin überrascht, immer, ich habe mich da schon ein paar Mal Gedanken gemacht und ich war immer überrascht, dass es da keine einfache fertige Arbeit gelöst ist.

Sondern dass man immer denkt, so, oh, ich habe die Antwort gefunden und dann irgendwie ein paar Monate, Jahre später kommt einer um die Ecke und sagt, was passt du denn da?

Das ist doch totaler Quatsch.

Ich bin schon seit Jahren nicht mehr.

Seit Jahren machen wir das nicht mehr.

Genau.

Und dann denkt man sich immer so, oh, okay, ich glaube, ich brauche Hilfe.

Okay, ja, okay.

Authentifizierung überhaupt.

Es ist erstaunlich ungelöst.

Es ist erstaunlich ungelöst.

Ja, REST ist ja erstmal keine, ist ja erstmal nur eine ganz normale HTTP-Webseite.

Also du kannst Authentifizierung machen mit allen Mechanismen, die du da halt auch kennst.

Ich meine, wir haben auch, wir haben alle die Webseiten gesehen, die die PHP-Session-Id als Get-Parameter drin hatten.

Dürfte man halt nicht kopieren.

Dann dürfte man halt die Links nicht verschicken, ne?

Ja.

Wie macht man denn sonst noch Rest-Apis mit Python?

Genau, also ja, also General Rest Framework, schöne Sache.

Ich glaube, in der Flask, ich weiß, weiß ich gar nicht, wenn man das ausspricht, vielleicht spricht man das auch J aus.

Nein?

Flask, Freeze.

Ich weiß es nicht, genau.

Ich spreche alle Sachen immer falsch aus, sonst hat bisher noch nie niemand.

Flaskke.

Flask.

JSON.

Jason, ja.

Genau, da verwendet man eher Marshmallow, das gibt es auch für Django, aber da verwendet man Django Rest Framebook, ja.

Was ist das jetzt wie der Marshmallow?

Ja, das ist auch eine Bibliothek.

So ähnlich wie Django Rest Framebook, aber im Grunde, ja.

Endpunkte.

Benutzt man ja noch Flask Jochen.

Ja, aber genau, da will Hot Take, ich würde ja sagen.

So, jetzt habe ich ja was ganz Gemeines.

Oh Joch, jetzt machst du die Tore für Flame Wars auf.

Hallo Adpython.

Der einzige Grund, Flask noch zu verwenden, ist ja so im Grunde, aus meiner Perspektive, ich kenne mich auch nicht wirklich mit Fass aus, aber wenn man alte Python-Versionen hat, weil ja, das geht mit Flask und vielleicht mit anderen Sachen nicht.

Aber wenn man jetzt größer Python 3.6 unterwegs ist, warum Flask?

Warum nimmt man da nicht sowas wie Farce API?

Also Meinung, wenn ich nicht nur eine API schreiben will.

Hallo.pythonpodcast.de, da könnt ihr gerne einen Kommentar und hast den an Jochen uns Kommentar jederzeit erwünscht hinterlassen.

Machen wir mal so eine Episode, wo wir die vorlesen einfach.

Die Mail?

Ja, das Problem ist, die ist dann aber keine zwei Stunden lang.

Ja, außerdem wollen wir ja nicht immer viele nette Nachrichten da.

Es gibt ein sehr schönes Buch von einem Science-Fiction-Autoren, das heißt Your Hate Mail Will Be Graded.

Wo er einfach Post, Fanpost, sagen wir es mal, in Anführungszeichen, die an ihn geschickt wurde, diskutiert.

Ja.

Und sowas, sowas, äh.

Jochen, du wirst jetzt sicherlich.

Ihr werdet jetzt, jetzt wurde es gesagt hast, dass Flask.

Das umfasst ja auch alle anderen alternativen APIs.

Alle anderen alternativen Systeme.

CherryPie, Pyramid, Reboze.

Nee, oh, Pyramid, oh, das hat man.

Es gab ja eine neue neue Version.

Pyramid 2.0, voll gut.

Nee, ich weiß es ehrlich gesagt gar nicht so genau, was passt.

Pyramid.

Ich weiß, die gibt es alle und so.

Manche davon können bestimmt auch voll coole Sachen.

Bei Soap, ja.

Ja, das war mal voll groß und so, aber ja, vielleicht ist es auch voll cool.

Es gibt noch Bottle oder sowas, heißt das nicht auch?

Aber das ist super, ja.

Bottle gibt es, ist super klein.

Ja, das ist kleiner als Flask, das ist ja, deshalb heißt es ja so.

Aber ich meine, tatsächlich Fast API würde ich jetzt aus meiner Perspektive, es macht im Grunde, dass das Fast macht, mehr oder weniger.

Hat auch, also nicht, ich weiß jetzt nicht im Vergleich der Flask, aber man hat mehr als das bei GitHub.

Auf jeden Fall als Bottle.

Na super.

Ja, aber das ist doch, also Fast API ist doch wirklich nur für APIs gedacht, oder?

Nee, du kannst, also ich habe damit auch schon Webseiten, du kannst das Problem, so ja, ist gedacht, aber es geht auch anders.

Du kannst da einfach Ginger 2 Templates verwenden und die Dinge ausliefern, gar kein Problem geht.

Und genau, du musst halt alles.

Starlet?

Genau, Starlet ist halt sozusagen das Ding darunter als, ähm, ja.

Die Werbung ist on par with Note.js and Go.

Ja.

Ja, das ist das besprechen wir in der Benchmark-Effice.

War das wieder ein Benchmark, der illegal war?

Aber du hast halt, aber ja, ich meine, ich mache in letzter Zeit schon auch so Dinge mit FastAPI und ich finde das super.

Ich finde gerade auch die Integration mit Pydentic echt nett.

Alle Leute, die sich damit nicht abfinden wollen, können auch bitte an welche Mailadresse schreiben.

Hallo at Python Podcast.

Def0 at Feinwall.

Naja.

Aber die Syntax ist halt besser.

Du hast halt da, das ist halt nativ ersynkt, direkt alles.

Die ganzen Geschichten sind halt, du könntest ja auch quasi in Django oder halt in den Serializern Sachen mit Hype-Annotationen halt sozusagen da die Typen festlegen oder so.

Geht nur nicht, weil das ist halt älter als Hype-Annotation, deswegen musste man sich da schon was anderes überlegen, ja, in Django mit den Dreptoren.

Aber in Fast API ist halt erst ab 3.6, das heißt, da kann man das halt so machen und dann hat man halt das in relativ eleganter Syntax ausgedrückt, wo man sonst eine Menge schreiben muss.

Ob es jetzt so schlimm ist, weiß ich auch nicht, aber es ist auf jeden Fall irgendwie so ein bisschen erfrischend.

Und was man halt auch geschenkt kriegt, ist, ja, das sind wir auch schon eher beim Restthema, ein Frontend, das aber nicht so wie bei Jungle Rest Framework so ein eingebautes, gerendertes Ding ist, sondern dass es halt sozusagen Swagger oder halt Open API heißt das jetzt irgendwie, dass sich aus dem Schema quasi das Frontend generiert.

Es ist ja quasi komplett JavaScript, aber ja, dem sagt man halt hier, so ist das Schema, dann macht es halt ein Frontend dazu, das tatsächlich auch so ähnlich ist wie jetzt bei Django Rest Framework.

Und das funktioniert eigentlich sehr gut.

Ja, sieht echt gut aus.

Und ist übrigens auch von Sebastian Ramirez, der auch Typer gemacht hat.

Und den hatten wir auch schon mal kurz ein, zweimal erwähnt.

Das ist schon interessante Sachen.

Da gab es doch noch was von dem einen, der Django Rest Framework gemacht hat.

Wie hieß es denn gleich noch?

Ja, das ist ja Tom, na, wie heißt er noch?

Christie.

Tom Christie, genau.

Ja, der hat auch Starlet gemacht.

Ah, ist das Starlet.

Wie hieß dieses, das hieß Star API oder irgendwie sowas?

Äh, Fast API, meinst du?

Nee, äh, dieser Standard, den er da sich ausgedacht hat.

Ach, ich weiß es jetzt nicht mehr.

Ah ja, das gab's auch.

Er hat auch ein API-Ding gemacht.

Ja, ja.

Aber ja, ob das.

Das war nur sehr kurzlebig, oder?

Ja, also jedenfalls habe ich davon dann irgendwann nichts mehr gehört.

Da waren auch coole Ideen dabei.

Da war zum Beispiel sowas dabei, wie, dass du dann halt auch gleich Kommandozeilen-Interface kriegst und so.

Aber irgendwie.

Was ist denn jetzt da?

LetterTöpfung wieder.

Das wären wir auch schon wieder so überschwung.

Das ist das, was unter, was Fast API darunter verwendet.

Ach gerade, das ist quasi von einem Blame-Entwickler, der Dung Rest-Framework gemacht hat und das hat dann Fast API benutzt.

Okay, mm.

Verstehe.

Cool, ADP.

Also Tom Christie macht eine Menge coole Sachen.

Der hat ja einen Nachfolger von Requests, also die Requests-Bibliothek hat so ein.

ATTP-X?

Genau, hat so ein bisschen ein Problem.

Und zwar einmal ist sie so slightly unmaintained, okay, so ein bisschen.

Und sie ist auch nicht Async.

Und zwar auch so gar nicht.

Und das ist ja heutzutage auch so ein bisschen doof, weil wenn schon alles Async wird, dann will man vielleicht auch so Async HTTP-Requests machen.

Und das geht halt mit Requests nicht.

Oder es geht schon, aber da muss man halt irgendwie sehr unheilige Dinge tun und irgendwie das in Threads machen und so.

Es geht halt nicht mit Async-IO oder so einfach.

Ja, und HTTP-X ist aber dann Async-fähig und hat halt quasi fast die gleiche API wie Requests.

Also bemüht sich auch quasi die gleiche API zu haben, sodass man das halt einfach quasi.

Man kann verwenden halt, wie man es gewohnt ist.

Genau, man kann es so verwenden, wie man es gewohnt ist.

Man verwendet einfach HTTPX anstelle von Requests.

Auch sehr nett.

Aber tatsächlich irgendwie ein bisschen langsam manchmal.

Ich weiß nicht so genau.

Naja.

Ich verwechsle es immer mit HTMX.

Das ist eine JavaScript-Bibliothek, die Elemente interaktiv macht.

Ja, das ist auch so.

Aber ich verwechsle es immer.

Ja, genau, also ja, das sind so, ich weiß nicht, ob ihr jetzt noch, also das ist eben Marshmallow, Jungle Rest Framework, Fast API mit Swagger Pylentic, man kann dieses Swagger Interface auch bei anderen APIs, man kann das auch mit Jungle Rest Framework verwenden.

Das machen ja auch viele.

Bei Marshmallow geht das bestimmt auch.

Ich weiß nicht, gibt es da sonst noch.

Ja, das ist doch das, was jetzt OpenAI ist, also dieses OpenA-API-Shape.

Ja, was dann zu einem Swagger-File.

Das ist da verlinkt.

Ja, aber jetzt, um sozusagen mal noch einen Schritt weiter zu gehen, Jochen, du hast es ja schon angekündigt oder angedeutet, wenn ich jetzt eben nicht mehr so ein Interface habe, was gut auf diese Einzelobjekte passt, um es jetzt mal so zu sagen, sondern wenn ich mehr Kontrolle darüber brauche, was ich genau abrufe und welche Attribute ich abrufe, wie könnte ich das denn machen?

Ja, genau, da kann man dann natürlich sowas nehmen wie GraphQL.

Das ist von Facebook, oder?

Das Facebook-Chaps entwickelt, im Wesentlichen, um genau diesen Use Case abzudecken, dass man eben Sachen aus diesem Social Graph abrufen kann, der sich nicht an die Standard-Objekt-Konventionen hält.

Ja, sie haben halt im Grunde genau das Problem, dass sie halt sehr viele unterschiedliche, in sehr vielen unterschiedlichen Kontexten halt diese Daten, so graffförmige Daten ja auch gerade, ich meine, da passt halt auch normales SQL.

Man könnte ja sonst auch normales SQL nehmen, ist auch, aber da passt das halt gar nicht so super drauf und dann GraphQL passt da besser und ja, gut, okay, ist auch wieder.

Ja, ist da immer bei SQL, was du

immer sicherheiten.

Wenn es lacht, ich hab das kurz übersehen, weil was war jetzt gerade der Joke dahinter?

Da war ein bisschen tieferer Joke hinter der

Jeder Softwareentwickler hat sich schon mal gedacht, wisst ihr was, ich mache meine Schnittstelle einfach so, dass ich SQL-Strings hinschicke und dann das Ergebnis zurückschicke.

Und das ist super genial, ja, weil das ist für die Entwickler genau das, was die Entwickler haben wollen.

Nur hast du damit halt, kannst du Sicherheit vergessen.

Kannst du keine Sicherheitsabfragen.

Kannst du mit SQL kannst du alles machen.

Ja, ja.

Und deshalb macht man das dann doch nicht, sondern denkt sich eben so Sprachen aus, wie zum Beispiel REST oder GraphQL.

Ja, genau.

Ich weiß gerade nicht, ob die HDB-Leute noch eine eigene Sprache da haben oder ob die auch GraphQL dann haben.

Was ist denn HDB?

Das sind auch, das sind eigentlich im Grunde die Leute hinter Python, äh, dieser ganzen Python-Async-Geschichte, hinter Async.io und so, da ja, die machen ein Ding namens HDB und ja, ist auch alles Async und so und eigentlich ziemlich cool.

Basiert auf Postgres auch.

Aber ich glaube, die hatten auch eine eigene Abfragesprache.

Also ich dachte nur so, das ist vielleicht eventuell eine Konkurrenz zu GraphQL oder so, ich weiß nicht so genau.

Also vielleicht nochmal ganz kurz zu dem Unterschied.

Also was REST jetzt macht, ist Objekte und damit kann man so dabei Quad machen und das eignet sich super für normales SQL.

Und GraphQL, nein, falsch.

Nee, da gibt es sowas gar nicht.

Du kannst bei REST kannst du halt nicht sagen, was du gerne hättest, oder du kriegst halt.

Genau, es sind immer einzelne Objekte und immer ganze Objekte.

Oder Listen von Objekten oder sowas.

Ja gut, du kannst halt natürlich unterschiedliche URLs machen, die dann unterschiedliche Sachen liefern, aber du kannst halt jetzt nicht, das wäre halt nicht Rest-Kompost.

Eigentlich.

Eigentlich, genau, hat jedes Objekt in REST seine eigene URL.

Und das Höchste der Gefühle ist, dass du halt Listen haben kannst, die bestimmte Eigenschaften haben.

Zum Beispiel entweder alle oder die, die in X verlinkt sind.

Dass du so Sublisten hast.

Dann kannst du natürlich noch Filter machen, aber das geht dann schon raus.

Weil dann hast du schon so Listen abgerufen, die eigentlich, die es eigentlich gar nicht gibt und das ist schon so.

Gar nicht Rest.

Eigentlich sollte es

nicht so.

Also ich sollte alle Abfragen einzeln machen, um zu gucken dann, ob die da drin sind und dann alle wieder wegschmeißen, die es nicht sind.

Nee, das ist nicht, aber diese Liste selber ist nicht, die wird nicht von REST beschrieben, weil diese Liste selber kein Objekt ist.

Das heißt, um diese Liste zu finden, musst du schon wieder mehr wissen, als in Hater was drin ist.

Weil die nirgendwo verlinkt sein kann.

Jetzt musst du nochmal kurz erklären, was Haterwas ist, das hat nämlich eben niemand verstanden.

Das sind diese Hypertext, also dass alles über einen Hyperlink erreichbar ist.

Deswegen nimmt man auch Hyper-Serializer beim Dungo Rest Framework.

Hyper-Link Serializer, genau, ja, das ist.

Genau, damit die Links alle korrekt drin sind, damit du draufklicken kannst, das ist eigentlich einer der Grundsätze, dass du sozusagen den API-Root anklickst und da steht dann drin, was es alles gibt, und dann klickst du da drauf und da steht dann drin, hier gibt es die Objekte vom Typ so und so und dann klickst du da drauf und dann kommt ein Objekt vom Typ so und so.

Dass alles, was es gibt, über einen Hyperlink erreichbar ist.

Und wenn du jetzt so Get-Parameter einführst, die Filter haben oder so, dann sind die nicht über einen, dann sind die nirgendwo verlinkt.

Die musst du kennen.

Und das ist schlecht, weil die, weil, weil dann ist deine API nicht mehr durchsichtig, sondern die ist jetzt undurchsichtig geworden.

Du findest das nicht in der API.

Vielleicht über Options?

Kann man sowas in die Options schreiben?

In den Options-Headers, da kriegst du eigentlich die Header zurück und dann müsstest du dir wieder irgendwelche X-Header überlegen, die auch nicht standardkonform sind, die du auch, von denen du auch wissen musst, dass du quasi die Header gucken musst, um das zu finden.

Das, was Django Rest Framework da macht, ist ja schon eine sehr gute Sache, ja, dass du die Dokumentation mit lieferst, kannst du die Dokumentation einschreiben.

In einem Swagger-File weiß ich gar nicht, wie das abgebildet werden würde.

Ich glaube, da gibt es auch eine Möglichkeit, Parameter zu definieren.

Aber es ist eben nicht mehr in der API selber drin, sondern es geht über die API hinaus.

Und das ist eigentlich nicht was, was man möchte.

Es ist nicht erfahrbar.

Gut, aber das ist ja schon wieder jetzt so das, wo es halt regnet, ne?

Und du willst halt, jeder möchte irgendwelche Dinge filtern.

Ja klar, und deshalb hat da jede REST API auch sowas.

Aber es ist eben nicht offensichtlich.

Wenn du die zum ersten Mal benutzt, dann weißt du nicht, dass es da ist.

Und du findest eventuell erst, wenn du sie fünf Jahre lang benutzt hast.

Und das ist eigentlich nicht gut.

Und GraphQL ist jetzt wieder so ein kleines bisschen ein Schritt in Richtung Remote Procedure Call, wo du eben nicht sagst, gib mir folgendes Objekt, sondern es ist mehr so, führe bitte folgende Abfrage aus.

Du hast halt eine Schritte von Objekten, die in einer Kette von Sindskette liegen.

Du hast halt auch nicht eine URL für die unterschiedlichen Geschichten, sondern du hast halt eine URL, an die alles geht.

Und es gibt nicht mehr Delete Pad Putsch Putsch.

Der mächtigste allerdings.

Aber auch sehr teuer.

Sehr tun zwei, Payment Required.

Funktioniert nicht immer.

Genau.

Es gibt eben diese ganzen Daten nicht, es gibt nur Post.

Das war's.

Und ja, das ist natürlich

andere Vor- und Nachteile.

Es hat halt andere Trade-Offs irgendwie.

Okay, also ich kann damit dann tiefer reingucken und bekomme andere, deutlich fokussiertere Daten schneller oder wurden jetzt bei Kraft.

Ja, eventuell schneller.

Insbesondere kannst du es steuern.

Du kannst sagen, ich habe jetzt in diesem Request brauche ich alle Objekte, die folgende Eigenschaften haben und dazu alle, die folgende Eigenschaften haben und davon aber nur das Attribut Name.

Und anstatt, dass du dann halt in deiner Übersichtsliste, so wie es bei REST ist, erstmal alle abrufen musst, um den Namen anzuzeigen, führst du halt diese eine Abfrage aus und kriegst die Liste der Namen zurück, die du dann direkt anzeigen kannst.

Also diese GraphQL-Channelstelle ist viel näher an so einem Datenbankinterface, jetzt ganz spezifisch für Graf-Datenbanken, als das REST ist.

Also eine Grafatenbanken.

Mehrt dann Sinn, wenn man sowas wie, ich versuche jetzt mal abstrakt zu visualisieren, wolkige Datenformen hat als tabellenförmige Datenformen.

Ja, wenn du, wenn du, wenn du, wenn du verschachtelte Strukturen hast, also wenn du zum Beispiel eine Liste von Freunden von Freunden hast oder Kommentare, die auf Kommentare zeigen, die irgendwie in so einer Graphenstruktur halt irgendwie angeordnet sind, weil dann wird es halt mit SQL immer so ein bisschen ätzen, das geht auch, aber ist halt dann, da muss man sich dann was einfallen lassen.

Also wenn ich in SQL jetzt denken würde, wenn ich zu viele Foring-Keys hätte in meinen einzelnen Daten.

Nee.

Nee.

Nee, rekursive, rekursive.

Genau, wenn du einen Baum hast oder einen Graphen im Allgemeinen.

Also dich auch in einer Kreis.

Das ist gar nicht so einfach das andere.

Was denn was denn deine Lieblingsgrafenstruktur in Datenbanken?

Ich weiß, dass der Autor von Fein CMS, der Treebird, ich weiß nicht genau, was der was ich eine ganze Zeit gemacht habe, ist NZZ.

Das geht eigentlich ganz gut.

Aber es ist halt schon echt haarig.

Also das ist schon so ja.

Mit Hilfe Paths sind die Abfragen so bescheuert, das ist schon cool, aber die Abfragen sind so blöd, die will man nicht so.

Ihr habt jetzt gerade wieder irgendwie Daten?

Dominik googelt.

Ja, also die Frage ist halt, wie bildet man solche Strukturen eigentlich in relationalen Datenbanken ab und das ist halt nicht so einfach.

Es gibt halt das, ja ist das grüne Buch von Juli Celko oder so, Trees and Hierarchies in SQL oder so.

Das kann man sich halt durchlesen, da stehen die ganzen Methoden, die man da verwenden kann, drin.

Aber tatsächlich, also das, was wir tun.

Die sind alle schlecht.

Die sind alle, ja.

Und die sind alle schlecht, die sind alle blöd.

Letztendlich, es ist einfach schwierig, Graf-Daten, also Vernetzungs-Vernetzwerke in eine Tabelle zu schreiben.

Weil in der Tabelle hast du einfach inhärent kannst du keine Netzwerke reinschreiben.

Und alles, was man da macht, ist ein Hack.

Und die haben alle Vor- und Nachteile und die sind alle schlecht so.

Und deshalb gibt es ja auch Graf-Datenbanken und eben andere NoSQL-Datenbanken, die dafür besser geeignet sind.

Ja, und ein klassisches Anwendungsbeispiel für sowas, wo man das dann halt braucht und wo man Schwierigkeiten mit, ist halt sowas wie, ja, wenn ich jetzt wissen will, was sind denn jetzt alles meine Freunde vierten Grades oder so, dann wird halt, ist halt auf einer SQL-Datenbank, ist halt kacke.

War das nicht irgendwie so eine Theorie, die sagte, dass man mit allen Freunden oder allen Leute, die in Fapswork gemacht haben,

sechsens in.

Genau, Small World Theorem, ja.

Sechs?

Ja.

Six Degrees of Separation heißt er.

Okay.

Six Degrees of Kevin Bacon heißt es auch, glaube ich, aber das noch war was anderes.

Ja, ja, ja, ja.

Ja, aber also wie gesagt, GraphQL ist quasi so ein Schritt in Richtung RPC wieder, wo ich eben einen Endpoint habe, wo ich alles hinschicke und dann aber dafür eben vergleichsweise komplexe Abfragen ausführen kann.

Ich kann da allerdings auch eben vergleichsweise komplexe Updates ausführen, dass ich eben sage, ich möchte gerne folgende Objekte holen und dann auch bearbeiten oder folgende Objekte holen und dann auch irgendeine Operation aus denen ausführen.

Und das ist sehr, sehr mächtig.

Aber es ist eben nicht mehr so erfahrbar.

Es ist nicht so durchsichtig wie eine REST API, weil man eben wieder darauf zurückgeht, dass man die Dokumentation hat, dass man die Namen von den Funktionen wissen muss, dass man die Attribute von den Objekten wissen muss und ich kann nicht Deep Links drauf machen.

Was bei einer API nicht ungeheuer schlimm ist, aber ja, es ist einfach mehr Wissen außenrum.

Ja, der Client wird halt viel, ist halt viel, viel, muss halt viel fetter sein, sozusagen.

Auch eine nette Geschichte, da kommt darauf an, welchen Client und welche Server und man so verwendet, aber man kann halt auch sowas machen wie Subscribe, dass man halt eine Query, die man eh stellen muss.

Also man muss sie eh hinschreiben, weil man ja irgendwie die Daten holt und dann sagt man halt, wenn man daran interessiert ist, Updates davon reaktiv zu bekommen, dann sagt man halt einfach nur Subscribe und dann kriegt man per Websocket halt Änderungen an dem Query-Set, auf das man subscribed ist.

Und dann kann man tatsächlich, wenn zwei Leute irgendwie den gleichen Kram editieren oder so, dann sieht man die Änderungen von einem anderen halt direkt oder so.

Das ist halt, geht alles automatisch.

Voll gut.

Ja, tolle Sachen.

Ich habe vor einer Weile was gefunden, das heißt Graffiti mit pH.

Graffiti.dev, das ist auch ein Link, der da rein muss, was mir sehr gut gefallen hat.

Ich weiß noch nicht, wie ich damit zurechtkomme und ob das.

Das ist so ein bisschen wie Ruby und Rails.

Ruby und Rails hat ja früher die ganzen coolen Sachen gekonnt, die Django, wo Django so ein bisschen langweilig war.

Und hier ist es jetzt wieder genauso.

Das ist so eine Ruby-Bibliothek, die so ein bisschen die Brücke schlägt zwischen REST und GraphQL.

Das ist quasi REST mit ganz vielen Konventionen, sodass du daraus so eine Art GraphQL machst.

Mit den Vorteilen von beiden Seiten.

Du kannst coole Queries ausführen, aber hast trotzdem die ganzen guten Vorteile.

Okay, interessant, mal angucken.

Ja, aber alle Beispiele sind in Ruby und ich habe noch nicht gefunden, ob das auch in Python oder gar in Django geht und das wäre sehr schön.

Diese Konzepte, die da drin sind, haben mir sehr gut gefallen, weil die halt sehr viel über Konventionen machen.

Es ist quasi eine Rest-Trintstelle mit ganz vielen Konventionen.

Und auch mit ganz vielen, wo dann eben Sachen über Datentypen laufen.

Also hier wird dann so eine Ressource definiert, die ein Attribut hat, was ein Name ist, was ein String ist, der sortable ist, der filtrable ist.

Und wenn du diese zwei Attribute hast, dann weißt du ja schon ganz viel darüber.

Dann weißt du schon ganz viele Operationen, die du da machen kannst.

Was dann eben wieder zurückgeht auf das, was der Dominik eben angesprochen hat.

Man braucht halt sortieren und Filtern und irgendwie muss man das abbilden.

Und warum nicht eine gängige Konvention machen und das dir Ressource mitgeben und sagen, okay, hier, da steht immer dieses, dass es sortierbar ist, ja oder nein, oder dass es beschreibbar ist, ja oder nein, dann reicht es doch aus, das zu wissen.

Und das ist quasi so eine Formalisierung davon, dass du nur noch diese Attribute hast und dann ganz viel daraus automatisch rausfällt.

Und das ist ein sehr schöner Ansatz, der vielleicht meiner Meinung nach auch sehr zukunftsweisend ist und auch noch nicht weit genug überall verfügbar ist.

Das heißt, du fragst einfach die API und weißt direkt, wie man die benutzen kann, ohne dass du weiter.

Du fragst quasi die API nach den Datentypen und aus den Datentypen ergeben sich dann Sachen.

Die API gibt dir auch zu den Datentypen die Operationen zurück, aber wenn da eben zu einem Feld Sortable drin steht, dann brauchst ja gar nichts mehr dazu sagen.

Weil das ist eine Standardsache, die jeder braucht und dann kannst du einfach sagen, okay, ich weiß jetzt, wie sortable, dass es auf diesem Feld sortable ist und ich weiß, wie Sortable auf diesem auf Feldern generell funktioniert oder auf Feldern vom Typ String funktioniert, dann kann ich da einfach diesen Sortable, diese Sortable Operation, diese Sortieroperation machen.

Und das ist so ein bisschen das, als ich das zum ersten Mal gelesen habe, war das auch so ein Moment, wo ich mir dachte, ah, das ist genau das, was beiden fehlt.

Das ist eigentlich die Vorteile von REST und die Vorteile von GraphQL zusammen.

Leider habe ich es noch nicht realisieren können, weil es eben, wie gesagt, so, ja, Installation, da steht dann, wie man es bei Ruby installiert und dann, gut, schade.

Also in meine Rails-Applikationen könnte ich das jetzt sehr leicht reintun.

Leider habe ich davon keine.

Ja, schade.

Klingt also hätte jemand Lust, ein Open Source-Projekt anzufangen.

Lust schon.

Falls ich Sponsoren für dieses Unternehmen finde, die melden sich bitte bei hallo atpodcast.de wäre sehr daran interessiert, da einen Sponsor zu finden.

Ich würde auch meinen üblichen Stundensatz reduzieren, selbstverständlich für Open Source Work.

Bisher habe ich keinen Sponsoren gefunden, der das bezahlen könnte.

Meine Firma ist leider nicht reich genug, um so was Großes anzugehen.

Aber jemand sollte das machen, absolut.

Ding schön.

Ja, ansonsten, genau, ich weiß nicht, auch interessant, diese Formate, die man da übertragen kann.

Dazu fällt mir gerade noch eine Geschichte ein.

Es gibt da so einen Podcast, den ich auch immer höre, weil mich dieses im Prinzip dieses ganze, weil ich diese, die, na, diese, oh Gott, Hölzchenstöckchen, ich fange immer noch weiter vorne an.

Wir kennen das schon Jochmig eigentlich

eigentlich allerdings.

Python Podcast ist ja sozusagen in Python Django selber gehostet.

Und ja, ich bin nicht so richtig super zufrieden damit, wie also es funktioniert schon so, aber so eigentlich würde mich natürlich nicht interessieren, wenn man das richtig macht.

Und da gibt es einen anderen Podcast, nämlich den Potlovers Podcast.

Und genau, den höre ich dann, weil da reden Leute darüber, wie sie das halt, also Podlove ist halt das WordPress-Plugin.

Das ist quasi ein Meta, ein Meta-Podcast, ein Podcast über

Podcast, ja.

Ja, oder über Podcasts tatsächlich, genau.

Und da dachte ich, ja, vielleicht dann, wenn ich das an, wenn ich da mal, also ich finde es auch tatsächlich, es ist ein super Ding und ich höre das und versuche mir dann die ganzen guten Ideen alle, versuche ich da zu stehlen und dann selber zu verwenden.

Und letztens gab es dazu eine interessante Episode zu den, auch zu Podcast-Clients und zu Feedparsingen und sowas.

Und also ich weiß jetzt gar nicht, möchte ich gar nicht da, es gab da einige Episoden schon, ich weiß jetzt nicht mehr genau welche, wo es darum ging, wie sollen denn die Formate und jetzt gibt es auch inzwischen Podcasts sind ja so relativ gehypte Geschichte auch und jetzt kommen Leute wieder auf die Idee, nachdem da seit zig Jahren, irgendwie über zehn Jahren lange nichts an den Standards passiert ist, oh, vielleicht können wir noch irgendwas an den Standards machen, weil vielleicht will man ja auch dann so ein paar Features ändern oder sich irgendwie abgrenzen oder keine

Ahnung, cooler sein als die anderen.

Und es gibt jetzt Podcastindex.org und so, wo halt, das sind auch Leute, die das schon ganz lange machen, sich halt wieder so überlegen, ob man da nicht noch irgendwelche neue, interessanten Dinge statisieren kann und so.

Und da ging es dann halt auch immer darum, okay, die ursprünglichen Standards zu Podcasts oder zu Blogs, irgendwie, das ist halt alles XML, ne, RSS.

RSS ist XML?

Ja.

Genau.

Und die Frage wäre halt, okay, und dann gab es irgendwie die Idee, oh, man könnte ja vielleicht auch JSON-Feeds nehmen.

So heute macht man ja eigentlich keine XML mehr so richtig.

Und wäre das nicht irgendwie besser?

Und dann war so, hatte ich so den Eindruck, da waren Leute doch, fanden XML eigentlich ganz cool und dachten so, nee, JSON, bar, warum denn?

Und lieber XML.

Und zum Rest hat man dieses Problem ja auch, dass man die Daten irgendwie übertragen muss und da habe ich auch so das Gefühl, so XML spielt im Grunde keine Rolle mehr, so richtig.

Und alle machen halt irgendwie JSON.

Ich weiß, man könnte es auch als CSV machen, hat das jemand schon mal gemacht?

Also ihr müsst aber kurz Grunde nennen, warum es überhaupt XML gut sein könnte.

Ich habe das nämlich letztens irgendwann mal gehört, dass irgendwie meinte, oh, XML wäre doch eigentlich total unterschätzt.

Ja, also weiß ich, also ich kann mir vorstellen, wie man auf die Idee kommt.

Ich würde das wahrscheinlich nicht sagen.

Also ich hatte eigentlich nie eine besonders hohe Meinung von XML und aber ich kann, ich kann in gewisser Weise verstehen, wie man aus einer theoretischen Perspektive sozusagen drauf kommt, dass das eine gute Idee wäre, weil viele der Probleme, die man sonst hat, wenn man das nicht macht, man ja vielleicht damit lösen könnte.

Also zum Beispiel eben, wenn man jetzt das vergleicht mit sowas wie CSV, was früher, also wenn man mit CSV Probleme hat, dann könnte man denken, dass XML vielleicht eine, ja, also man könnte sich vorstellen, dass XML vielleicht eine gute Idee ist, wenn man jetzt schon mal vorher so.

Das ist immer eine gute Idee.

Da kann man alles machen.

Ja, kann man.

Tatsächlich, aber ja, also wenn man jetzt vorher, wenn man jetzt irgendwie sowas wie CSV hat und man hat jetzt da Probleme, weil irgendwie Leute schreiben da komische Sachen rein und Dinge gehen kaputt, wenn man sich denken so, mir reicht's, diese Barbaren, immer was die da für komische Sachen.

Also tatsächlich, ich habe auch einige Zeit im Import-Export-Geschäft sozusagen von solchen Daten verbracht.

Und da passieren halt die komischsten Sachen, dass halt irgendwie das Encoding wechselt von Zeile zu Zeile, dass IDs halt keine IDs sind, dass irgendwie das Escaping sehr kreativ anders ist und das hat halt damit zu tun, dass halt da Daten aggregiert werden aus unterschiedlichen Datenquellen, dass die dann irgendwie nochmal als Excel irgendjemandem auf dem Tisch landen und der editiert dann fröhlich drin rum, speichert es wieder als was anderes und schickt es dann nochmal raus oder so.

Also da passieren dann wilde Sachen.

Und da könnte man sich jetzt denken, oh super, nehme ich doch XML.

Habe ich dieses Problem gelöst?

Dann sind alle Probleme gelöst.

Da sind alle Probleme gelöst, weil da habe ich ein Schema, da steht drin, was das ist.

Und wenn da jemand dann Mist macht, dann geht das einfach gar nicht.

Es schaut die Spezifikation quasi mit in der Datei.

Ja, ein Schema.

In einer anderen Datei.

In einer anderen Datei, die genau.

Aber ja, tatsächlich ist es aber so, also ich würde sagen, eben, es klingt danach, als wäre das eine Lösung praktisch.

Jetzt so aus diesem Tagesimport-Export-Geschäft mit vielen Dateien, die da reinkommen und rausgehen und unterschiedlichen Anforderungen und komplizierten und komischen Systemen dahinter und seltsamen Leuten und so, muss ich sagen, wir haben dann irgendwie, also XML und CSV gehabt und wir haben immer CSV empfohlen.

Und XML hat zu vielen fiesen Problemen geführt, die ehrlich gesagt schlimmer waren als das, was wir mit CSV haben.

Aber nicht die Encodings.

Nicht die Encodings.

Das Encoding war okay, ja.

Encodings sind gut bei XML.

Ja.

Naja, gut, manchmal kriegt man auch so komische Byteorder-Marker vorne dran, die dann irgendwie auch Sachen kaputt machen.

Aber ja, tatsächlich, aber das Problem ist halt, wenn du, wenn du den Leuten halt sozusagen ein oder aus, das wäre sozusagen das Ding, was ich dazu mitgeben wollen würde, und die Anekdote dazu wäre halt, wenn man, wenn man es unmöglich macht, dass solche Fehler passieren, dass halt zum Beispiel das Encoding pro Zeile sich ändert oder so, dann kann es sein, dass das dazu fü

hrt, dass die Fehler schlimmer werden und nicht besser.

Nämlich, was dann halt tatsächlich passiert, was man dann beobachtet, was ist die Konsequenz, wenn man das unmöglich macht, dass solche Fehler passieren, nun ja, dann kriegt man halt Dateien, die zwar syntaktisch okay sind, aber die semantisch halt irgendwie nicht mehr funktionieren, wo dann zum Beispiel Teile einfach fehlen oder die leer sind.

Die sind dann ein gültiges XML-Dokument, aber es ist halt irgendwie leer.

Und dann ist halt die Frage, okay, was macht man denn?

Ja, oder du hast es dann, oder hast dann die Fehler in den Daten drin.

Ich meine, wir haben ja alle schon mal diese UTF8-Steuerzeichen in Latin One-Dingern drin gesehen.

Und wenn das jemand reinkopiert, dann ist halt so.

Und dann kannst du auch nicht mehr viel machen.

Genau, und dann, das ist nämlich der Punkt, wo es dann eben, wenn dann Fehler passieren auf einer anderen Ebene oder halt so, dass der XML-Parser sagt, alles okay, aber es ist eigentlich gar nicht okay, dann kannst du nicht mehr viel tun.

Bei einem CSV, wo das, da kann man immer noch was tun.

Wenn da irgendwie eine Exception fliegt, dann kann man die immer noch fangen und kann sagen, okay, den Kunden kenne ich.

Der kann sich nicht einigen, ob er da jetzt Death One oder UTF8 oder CP51, weiß ich nicht, das Windows-Dings da verwendet oder so.

Ja, ja, ist schon okay, dann probieren wir die mal der Reihe nach durch und einer von den Codex wird schon funktionieren.

Meistens funktioniert es auch.

Und selbst wenn es nicht funktioniert, dann ist halt eine Zeile kaputt oder so.

Was oft nicht so schlimm ist.

Wenn einer von 10.000 Zeilen kaputt ist, na gut.

Das sozusagen degraded gracefully, sozusagen irgendwie.

Naja, das ist eine sehr interessante Beschreibung von Graceful Decred.

Es kommt vielleicht auch drauf an, welche Zeile das war.

Aber im Endeffekt, da werden Leute nicht wütend oder rufen an, deswegen, oder so, wenn da eine Zeile nicht okay war.

Wenn das XML leer war und man jetzt raten muss, was passiert ist, möchte der Kunde zum Beispiel alle seine Angebote löschen.

Weil wenn man es definiert hat, wenn das ein leeres Ding ist, dann macht man dann.

Oder offline schalten, dann kann man das tun.

Das könnte Ärger geben.

Oder man macht es nicht.

Das könnte ja auch Ärger geben, weil vielleicht wollte er es ja tatsächlich machen.

Also man muss halt irgendwie dann raten und das ist halt doof, weil jede dieser Entscheidungen, die man trifft, kann halt potenziell entweder bei einem selber zu irgendwie größeren Problemen und Geldverlust oder beim Kunden zu größeren Problemen und Geldverlust führen.

Und das ist halt schlecht, weil das ist halt nicht so richtig gracefully.

Und ja.

Das ist so ein bisschen wie diese statistische interessante Anormalität.

Als man die Helmpflicht für Motorräder eingeführt hat, ist die Zahl der Kopfverletzungen gestiegen.

Und der Grund ist halt einfach, dass die Leute, die vorher gestorben sind, jetzt Kopfverletzungen haben.

Ah, okay.

Und so ein bisschen ist es da halt auch.

Du schließt die einfachen Fehler aus.

Und deshalb kommen jetzt halt die schlimmen Fehler.

Ja, eine andere Möglichkeit wäre auch noch, dass die Leute, die vorher Fahrrad gefahren sind, jetzt dann halt irgendwie Auto fahren und dann die Wahrscheinlichkeit für Kopfverletzungen im Auto steigt oder sowas.

Ja, genau, viele unabsehbare Konsequenzen.

Unintended Consequences.

Externe Effekte.

Ja, insofern.

Jetzt haben wir zu viel über XML geredet in der Restfolge, ehrlich gesagt.

Ja, das ist ja nicht ausgeschlossen.

Du kannst ja, wie auch Junker Rest Framework bietet ja den XML-System.

Will das dann lesen, wer will das denn parsen, wer will das denn weiterverarbeiten, das ist doch alles total hässlich und dann.

Ja, kann doch sein, dass du irgendeinen Client hast, der das halt gerne haben will.

Für Entity und Attributes of Attributes of Attributes of Entities, bah.

XML hat ja auch Vorteile.

Zähle uns die doch bitte auf, Jonathan.

Nein.

Ich weiß, dass es welche hat, aber ich will sie jetzt nicht sagen, weil ich will niemanden dazu verführen.

Na gut.

Ja, ein anderes Format, auf dem man auch noch gut rumhalten könnte, wäre JSON.

Das ist, ich meine tatsächlich, ehrlich gesagt, es hat auch so diverse Hässlichkeiten und so.

Aber JSON funktioniert eigentlich schon.

Also das kann man eigentlich auch.

Also man kann das schon nehmen.

Es ist nicht so schlimm.

Ja.

Ich bin mal ein großer Freund von Message Pack.

Ja, ja, ich weiß.

Was ist das Message Pack?

Message Pack ist quasi binäres und gepacktes JSON.

BJSON.

Sagt man das so?

Ja, BJSON ist nochmal was anderes.

Und es gibt auch BSON, also B-S-O-N.

Das Binary Serialized Object Notation oder sowas.

Ist auch was anderes.

Das ist das, was in Postgres drin ist.

Und da gibt es noch HSON.

Das weiß ich nicht, was es ist.

Das ist auch in Postgres drin.

Das ist, glaube ich, die ältere Variante, aber ja.

Ja, kann sein.

Ja, Message Pack ist quasi ein Drop-in-Replacement für JSON, nur schneller und kleiner.

Das kann man, glaube ich, bei Django Rest Framework kann man das auch irgendwie mit dazu konfigurieren.

Ja, klar, das ist halt auch so ein Standard, ah, die heißen nicht Serializer, sondern heißen irgendwie anders.

Es muss man halt in der Konfiguration angeben als Klasse und die haben ja ihre Abfolge und wenn der Client nichts sagt, dann kriegt das halt in der richtigen.

Ich glaube, die heißen irgendwie Renderer oder sowas.

Ja, das kann sein.

Früher war das tatsächlich, konnte man tatsächlich sehr schöne Dinge machen, weil halt Message Pack-Nachrichten kleiner sind als JSON-Nachrichten.

Und in einem Mobile-Umfeld war das früher ein sehr wichtiger, sehr wichtiger Aspekt, dass man unter 65 Kilobyte bleibt, weil das eben ein Datenpaket war.

Früher, damals, als es noch 3G gab oder 2G oder was auch immer.

Und da war Message Pack richtig, war ein richtiger cooler Vorteil, weil du halt nichts machen musstest und trotzdem unter den 65k geblieben bist normalerweise.

Und das war damals wichtiger.

Heutzutage ist es wichtiger, dass es lesbar ist, deshalb blimmt man die bei JSON.

Ja.

Ja, oder andere Leute, die direkt komplett alle Daten, wenn man nicht viele Daten hat, was man auch ganz gut machen kann, ist, man zieht einfach alle Daten komplett.

Ja.

Weil man dann halt auch die Antenne nicht so, das ist ja auch sowas, ne?

Stromverbrauch und die Antenne anschaltet.

Ja, macht man auch nicht mehr so häufig.

Ja, eigentlich ist es ja auch.

Ich meine, jetzt haben wir sehr viel über REST gesprochen und über Alternativen.

Im Grunde ist REST ja was ganz Simples.

Es ist einfach nur die HTTP und HTML angewendet, äh, nicht HTML, HTTP angewendet auf APIs.

Und ja, so sollte man das machen.

So wäre es gut, wenn man das macht.

Und das ist ja schon.

Oh, eine Sache, die ich ganz interessant finde, die eventuell nochmal dazu führen könnte, dass es halt so ein bisschen Renaissance in die Richtung gibt, weil man, vielleicht kann man Teile von dem, was man jetzt mit GraphQL macht, auch dadurch erreichen, dass man Endpunkte miteinander kombiniert oder irgendwelche Aggregationsendpunkte macht.

Und die dann halt per Async, also normalerweise sagen so, ja, viele Requests machen, nicht so cool, weil blockiert halt immer alle immer einen Worker im Applikationsserver, aber wenn man jetzt Async hat, dann ist es vielleicht auch egal.

Und dann kann man sich sozusagen seine Ergebnissets auch so ein bisschen darüber zusammenbasteln und diese Dinger halt Endpunkte vielleicht so on the fly generieren oder weiß ich nicht.

Naja.

Ja, aber zu diesen, äh, da gibt es übrigens einen Artikel zu, wenn ich jetzt mal da Werbung machen.

Darf auf deinem Blog, Jochen, über diese Async-Agggregations-API, hast du da einen kleinen Beitrag zugeschrieben.

Achso, ne, da, da, da, das, ja, das ist aber sozusagen nur quasi, wenn man andere APIs abfragt.

Das ist natürlich auch ein Anwendungsfall für iSync, genau, weil eben man dann halt nur auf den, die Zeit, die Latenz ist nur die Zeit, die der längst laufende Request braucht und nicht mehr, wenn man das synchron abfragt, halt alle aufsummiert.

Und genau, aber es wäre ja auch sozusagen, wenn diese, wenn diese Dinge, die man fragt, interne andere API-Endpoints sind und man dann irgendwie noch eine Transformation drauf macht und das dann rausschickt.

Microservices.

Ja.

Buzzword Bingo.

Meine Consulting-Kosten haben sich eben verdoppelt.

Ja, wobei Microservice-Integration würde ich ehrlich gesagt auch nicht unbedingt über REST oder HTTP machen.

Oder macht ihr, ich weiß nicht, wie der das Neues macht.

Sondern über was?

Wahrscheinlich über eine Message Queen.

Einfach deswegen, weil du dann zum Beispiel Balbur umgebracht.

Ja, und weil du bei HTTP hast du halt diesen Overhead immer der Verbindungen, die du aufmachen musst und den

bist du ja mit Techniken weg.

Ja, und intern musst du dann vielleicht auch nicht immer authentifizieren und sowas, aber ja.

Ja, okay, wie auch immer.

Darauf müssen wir auch nochmal sagen.

Würdest du noch was anderes sagen, ja?

Genau, also das wäre halt vielleicht ein Ding, wie man sozusagen damit umgehen könnte, dass man ansonsten eine Explosion von Endpunkten hat und ganz viele Abfragen machen muss, wenn man bei Rest im Vergleich zu UFGL.

Aber ja.

Okay.

Keine Ahnung.

Ja, okay.

Ich würde auch sagen, wir haben ziemlich viel bei Rest heute gesagt.

Habt ihr noch irgendwas auf eurer Liste, was ihr noch losenwerden wollt heute?

Weil sonst würde ich nämlich sagen, Punktmas.

Nö, ich habe sonst auch nichts mehr.

Ich fand es schön, viel wieder gelernt.

Ich hoffe, ihr werdet uns weitergewogen, hört uns weiter.

Schreibt uns unser Feedback, euer Lob, hast Kommentare, alles, was ihr loswerden wollt an hallo.peistenpodcast.de.

Schön, dass ihr wieder eingeschaltet habt.

Vielen Dank, dass ihr wieder alle dabei wart.

Vielen Dank, Johannes.

Und ja, hört uns das nächste Mal wieder.

Alles klar.

Bis dann.

Jo, tschüss.

Wir haben die Pics vergessen.

Machen wir dann heute nicht.

Tö, töte.