Transcript: REST

Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python-Podcast, heute in der 29. Episode.

Wir machen heute REST, 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, Glück! 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, den frage ich dann zuerst, was ist denn das?

Ja, ich dachte, wir wollen nicht

vielleicht zuerst ein News machen, weil ich habe da auch noch so ein paar Sachen...

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

Oh, da kommen wir nicht mehr zu den News.

Doch, die kommen noch zu den News.

Na gut, okay, machen wir es jetzt andersrum.

Erklär mal ganz kurz, was REST ist. Aber nur ganz kurz.

Ja, das ist Elevator-Fischung.

Also,

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

Ne, warte mal.

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.

Genau, das ist das Web.

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.

Jetzt suchen wir das Objekt News ab.

Jetzt machen wir News?

Ja, jetzt machen wir News.

Gut, okay, machen wir ein News.

Python 3.9.2.

Pattern Matching.

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

Alle anderen Punkte sind unwichtig.

Pattern Matching.

Case, Switch, Case.

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

Nur ganz am Rande.

Ich fand das so gut, dass ich direkt einen Blogartikel auf meinen selten benutztes Blog geschrieben habe,

weil das so wichtig ist und so toll, dass ich, ja klar, kriegt ihr natürlich einen Link dazu.

dass ich das sofort schreiben musste

und

Pattern Matching 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 habe es aber irgendwann vergessen, dass es das in Python

nicht gibt

und jetzt gibt es es irgendwann

endlich wieder.

Ja, aber es gibt doch If-Else, warum brauche ich denn dann ein

Switchcase? Ja, das ist prinzipiell

richtig, man kann das alles mit If-Else machen,

man kann auch prinzipiell jede Schleife

aus While-Loops machen, man kann prinzipiell

auch alles aus Goto zusammenbauen,

man macht es nicht, weil es 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 zu

schreiben. Was ist ein Variable 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 Blogartikel 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, case int und dann ist es ein int oder case dr, dann ist es ein dr. 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

beim Walrus

Operator.

Ja, auch bei den Typen,

bei den Type Annotations.

Ja, aber die sind auch, 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

hinter schreiben 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

und dann kann man da zwei

verschiedene Typen haben und so, das 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 das

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

Das ist ja das Schöne

Genau, genau.

Und da, wo es halt Sinn macht,

da kann man es dann halt dazu tun

und dann ist es auch nett. Ich finde auch tatsächlich,

das mache ich in letzter Zeit häufiger,

entweder

Dataclasses,

oder Pydentic verwenden

und tatsächlich Klassen

so hinzuschreiben, ist deutlich

angenehmer als das irgendwie...

Hatten wir Pydentic schon mal?

Ja, ich weiß nicht genau,

ob ich es mal gepickt hatte

oder so. Kann sein.

Was macht Pydentic?

Du hast 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

die

diese Art

sozusagen das Klassen hinzuschreiben

sowieso irgendwie macht irgendwie

nett. Ich sehe, ich habe auch schon

irgendwie hier in Pydentic in der Doku mal rumgewühlt.

Also eigentlich wollte ich wissen, was das ist.

Ja, das ist so

eine Art Mischung aus

MyPy und Dataclasses, oder?

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?

REST ist das denn, Jochen?

Ja, Moment

Erstmal die Reste der News, bitte

Was haben wir denn da noch?

so ein Pattern Matching

ja, coole Sachen, 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

aber Async PG ist auch so ein Ding

was man sich unbedingt mal angucken kann

wovon hast du gerade gesprochen?

ja, UV Loop ist halt so eine schnelle

also ist die

Python-Version oder

Abstraktionen-Drapper

um LibUV und das ist eine super schnelle

Abstraktion über

die ganzen

betriebssystemspezifischen Schnittstellen,

sowas wie EpoL oder KQ oder

was weiß ich nicht, was da sonst so.

TCP Completion Ports oder

I.O. Completion Ports.

Ich glaube, das ist mehr Stuff

für die Web-Server-Folge, die wir immer machen.

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 darunter liegt. Und genau

davon gab es jetzt gerade eine neue Version und

Async-PG

ist halt ein 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 saukool, wenn man das

Async machen könnte und Async-PG ist auch

richtig schnell. Async auf Datenbank

stelle ich mir schwierig vor mit Transaktionen und so, weil

Nö, das ist alles, eigentlich

ist das überhaupt kein Problem. Also

Es gibt halt nur einen Warenzustand dann immer

und das ist egal

Du kannst ja auch sonst auch

Du kannst ja schon mehrere Sachen gleichzeitig machen

Nur ist es halt so, dass du normalerweise

dann halt warten musst

Du schickst halt irgendwie

Es fällt immer an die Datenbank und dann blockierst du halt

ein Code

Du machst es halt synchron

Das ändert nicht die Datenbank, Dominik

Sondern es ändert nur, wie du die Verbindung der Datenbank hältst

Ja

Aber wo wir gerade bei PsychoPG sind

PsychoPG3 ist angekündigt

und was du 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 war mir halt nicht so

und Jochen unterhalten sich über die Programmiersprache Python

Ja

Ja, aber Pooling 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 gab irgendwie einen Artikel

zu Security-Geschichten

Dependency-Conclusion

Ich weiß nicht, ob ihr den auch gelesen habt

Gab es einen Artikel zu?

Es gab da schon ein paar Artikel zu.

Dependency Confusion.

Ja, sehr deprimierendes Problem, ehrlich gesagt.

Das musst du aber denken, was ist Dependency Confusion?

Ja, da gab es doch so ein,

da hat doch eine dreieinhalbtausend Sachen bei PyPy hochgeladen, oder?

Ja.

Und genau,

das ist halt so, oft,

wenn da Leute die Version,

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

genau

dann kann man das sozusagen hijacken

und dann kann man den Software installieren

die auch im Großen und Ganzen

das tut, was sie 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

und macht halt gleichzeitig 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 3.500 solche Bibliotheken auf PyPI 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.

und hat da auch überall

quasi das

Preisgeld dafür gekriegt,

die man halt für

Millionenweise.

Also 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 helfen, oder?

Wenn ich jetzt irgendwie die Hashes von Independent ziehe damit.

Nein, leider nicht.

Nein, warum?

Weil du ja immer noch den Namen eingeben musst

irgendwann.

Ja, aber wenn das bei einer

PyProject-Hummel schon gepinnt ist, richtig

Dann hoffe ich mal, dass du

die richtige gepinnt hast

Zum ersten Mal muss ich aufpassen, wenn ich das

eintrage, aber

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 PyPy auf den Rechner holt oder Node.js

oder was auch immer und irgendwelche Pakete von irgendwo installiert, ohne 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, das Problem haben wir an vielen Stellen, das haben wir natürlich auch bei Docker zum Beispiel, wenn man sich da irgendwelche

Images sieht, wo man nicht weiß, was da drin ist. Das Problem haben wir auch bei Distributionen, aber jetzt wenn man

eine Distribution nimmt und man installiert

per Apt 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

sich reinholt,

kann man 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 daraus 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-Version haben die gerade?

Genau, das ist

das Problem.

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 irgendwoher, sondern wir wollen die Betriebssystempakete

haben und dann hast du ein echtes Problem. Ja, dann haben die doch keine Software mehr.

Viele, viele Sachen. Ja, bist halt bei Django 2. irgendwas. 1. 2.0.

Ja, aber ist doch Quatsch. Also dann mache ich doch lieber irgendeinen Server auf, der vielleicht

kompromittiert werden kann und mache dann andere Sachen sicher. Mache dann Singles

Point of Truth 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

COS ist.

Cross Origin Requests

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

und ich weiß, dass das sehr gut ist, weil das bedeutet

dass man nicht einfach irgendwoher

Ressourcen abrufen kann

Resource Sharing? Ah, okay

Cross-Original 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, genau so habe ich auch reagiert

Das war mir jetzt nicht klar

Oh shit

Aha!

Genau.

Also die Annahme ist, dass der

Server das macht, dass der den Origin-Header

überprüft und das dann halt ablehnt.

Aber prinzipiell

muss er das nicht. Im Prinzip kannst du eine Verbindung

irgendwo hin aufmachen und sagen,

ich bin der Websocket von so und so.

Und ja.

Also das ist doch so eine Sache, wenn das im Header drinstehen müsste,

macht dann nicht sowas wie

Django Channels sowas in den

Headers mit...

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...

Das ist immer, wenn es

so ganz überraschend und komisch ist,

dann ist es kein gutes Zeichen.

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 dem Feature.

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

Das ist ja sehr gut.

Was uns zu unserem Topic

drücken könnte, wenn ihr denn mit den News von so weit 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

vorletzte Woche oder sowas.

Letzte? Ich weiß nicht mehr genau.

Da müsste man jetzt ein Glas Sekt aufmachen.

Ja, müsste man jetzt eigentlich.

Ja, ist jetzt Python offiziell 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,

das ist alles nur, was du gehört hast,

was du gelesen hast.

Genau.

Das ist eine Tarnung.

Ja, wenn man letzten Montag in einem Schaltjahr geboren

worden wäre, dann hätte man tatsächlich das Problem gehabt,

und Jochen unterhalten sich über die Programmiersprache Python

Du hattest mir, Johannes, glaub ich mal

so einen Link geschickt auf so einen Benchmark

Ja, oh

Da arbeiten wir jetzt auch schon eine Weile

dran, Jochen

Ja, und genau, da ging

auch über Hacker-News und dann

war es irgendwie, war da auch bei Python-Bytes drin

und so und da ging es darum

da hatte ja jemand irgendwie, weiß nicht genau

was da, also da ging es halt um

Jemand hat irgendwas gebenchmarked

Und das Einzige, was ich dazu im Grunde

nur anmerken wollte, also

also

mit so einem Körnchen Salz

sollte man da vielleicht

mit dazu tun.

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

Das ist das, was ich da raushöre.

Genau.

Ich könnte das bestimmt fortsetzen.

Lügen, dreiste Lügen.

Haben kurz...

Nee, halt, warte.

Benchmark.

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.

Wir wollen beweisen, dass Python

die schnellste Sprache ist unter der Sonne.

Nee, aber vielleicht schnell genug.

Wir wollen beweisen, wie man damit schnell

sein kann.

Oh, das ist ein Thema

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

Dann machen wir eine eigene Geschichte zu.

Okay, ich wollte nur sagen, also wenn man

jetzt diesen Artikel sich anguckt, vielleicht 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, dass ich es dann so angucke,

wie wenn da so

HTTP-Doodles oder

bei Scenic ist das dann installiert und im anderen

nicht und HTTP-Parsing kann ja dann

das Nadelöhrer, also ich will gar nicht

anfangen davon, stimmt,

da machen wir mal 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, gut.

Jetzt dachte ich, Entschuldigung, jetzt müsst ihr mir das erzählen.

Jetzt bin ich sonst die ganze Zeit neugierig.

Jochen hat einfach schon sehr viele Dinge ausprobiert

und wir haben es bisher nicht geschafft,

so viel Bandbreite zu verbrauchen,

dass wir mehr Bandbreite,

also dass wir

ein Netzwerk sinnvoll

benutzen hätten können.

Also das war das mit dem Gigabit, was du nicht kriegst

ausgelastet.

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

Was war dein erstes Ergebnis? Wie viele

Kilobit hast du?

Schon ein paar Megabyte pro Sekunde,

aber halt noch...

Weit entfernt.

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

Ja, also es geht darum, dass halt die Konkurrenz von

Python-Web-Applikationen

oder was ging's?

Nee, also das Ziel da war es 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, 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's dafür eigentlich

jetzt noch so einen Grund, weil tatsächlich

kann man ja mit Async und der ganzen Wintergut

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?

Also wenn ich jetzt 100 Gigabit saturieren möchte

Hm, okay, dann

nehme ich vielleicht doch was anderes

Aber wenn

ich jetzt sowieso relativ

wenn ich jetzt sagen wir mal nur so ein Gigabit habe oder so an einem Server

Dann kann es ja sein, dass es

völlig egal ist, ob ich NGTX 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 hört ihr weiter in unserer Webseite

Genau, dann haben wir das ein bisschen

ange teasert, aber genau. In der Benchmark-Episode.

Ja.

Genau. Wir wollten nämlich noch eine

Datentypen-Folge machen, die haben wir auch noch aufgeschoben.

Nur für alle, die sich dann überräumen.

Ja.

Ja, okay.

Ja, ist eine spannende Sache.

Da gibt es viele schöne Dinge.

Ich habe noch was zum Thema Web-Server.

Habe ich kürzlich gefunden. Fly.io.

Habe es noch nicht selber

ausprobiert, aber das scheint so ein bisschen

wie das developerfreundliche

Heroku zu sein.

Mit einfachem

Deployment überall.

Wo man

quasi einfach Docker-Container hinschickt

und die lassen wieder laufen, wo man sie haben möchte.

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 noch keine Gelegenheit gehabt, das auszuprobieren,

aber ich habe mir vorgenommen,

das auszuprobieren.

Sehr cool, weil da gab es mich, das habe ich heute irgendwann gehört,

glaube ich,

auch eine neue Episode vom Django Chat Podcast,

wo Peter Baumgartner

von Lincoln Group,

der auch dieses High-Performance-Django-Buch,

der hat das, glaube ich, geschrieben

und der hat auch so ein Ding

gebaut. 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... Und viel Geld hat.

Und viel Geld hat, ist halt recht teuer und es ist halt auch

so, dass deren...

Es ist doch eher so 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.

Um es mal so vorsichtig zu formulieren.

Und der hat 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, ist schön zu sehen, dass es da mehr Optionen gibt.

Spannend, dass es so viele Firmen

im indischen Ozean gibt, das ist schon

sehr cool

IO ist für den indischen Ozean

Achso

Ja, der indische Ozean hat mal

ausnahmsweise mal was richtig gemacht

mit der Wahl des Problems

Ja, Glück gehabt

Glück gehabt

Ja

Pack IO sagst du, Jochen

du tust uns den Linker sicherlich

Genau, Uppack mit 3P.

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

Naja, aber genau, ich tue den Link in die Shownotes,

dann kann man sich das angucken.

Ja.

Jetzt haben wir nur noch Reste übrig, oder?

Ja, jetzt haben wir nur noch Reste übrig.

Es ist nur noch der Rest.

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

Ja.

Also, wo waren wir eben stehen geblieben, Johannes?

Representationist?

Ja, im Vergleich zu Remote Procedure Call.

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 ein Endpoint, wie auch immer,

der geartet ist, ja.

Java, XML,

LPC.

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

Ja, das hatten wir auch.

Sprich es ruhig aus, so wie es früher war,

das SOAP zum Beispiel.

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 einen Roboter starten oder die können die Kamera oder keine Ahnung,

irgendwas können die machen.

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 gemacht hatte und das 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 gar nichts und diese Interfaces bauen war auch ganz schrecklich

und Jochen unterhalten sich über die Programmiersprache Python

Also ich weiß es natürlich nicht, 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 Soap oder auch

Sachen, wo dann andere Leute versucht haben, Korba

irgendwie zu retten

in der Webwelt, macht, dass man sagt, ja

ihr habt hier so ein altes, überholtes

Architekturmodell, von dem wie

eure verteilte Anwendung funktionieren soll

und jetzt versucht er jetzt,

das Web zu degradieren, dass das nur

ein Transport-Layer ist für eure Idee,

die auch schon vorher eigentlich

nicht funktioniert hat.

Was war in Form war?

Da gibt es eine

schöne Organisation mit dem Kürzel

OMG.

Oh mein Gott.

Common Object Request Broker Architecture.

Genau, und die hat das

standardisiert. Das ist die Object Management

Group.

Ich hatte auch

Ich hatte viel Spaß mit Cobra

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 an große Schmerzen.

Okay, und in

HTTP selbst ist dann sowas eingebaut

wie, gib mir ein,

oder bekommen ein Objekt.

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?

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 das per Patch. Wenn du das Objekt

in einer Version

änderst, dann puttest du das komplett.

Und Post?

Post es hinzufügen.

Ja, aber das ist ja auch nicht so.

Das ist ja bei REST auch nochmal anders geregelt.

Das ist ja, wenn du auf eine ID postest,

puttest, dann ist es ein

neues Objekt mit dieser, wenn es die

noch nicht gibt, dann ist es neues und wenn du auf eine

Ja, so ganz klar.

Ja, ehrlich gesagt

weiß ich auch nicht. Also braucht man nur noch zwei.

Get und Post.

Ja, das ist halt das, was viele Leute machen. Mit denen kommt man zurecht.

Mit denen kommt man schon zurecht, aber das ist

natürlich. Delete brauchst du noch, Dominik.

Delete brauchst du für den Körner. Na gut.

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

Du kannst, 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-Werben.

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 kein Attribut.

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

Delete ist eindeutig.

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

Wenn ich eine URL habe, wenn ich einen Pfad habe, der 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 brauchen wir ums Löschen

Das geht immer.

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

Nein.

Genau, mit Post löscht du nie.

Post und Put und Patch sind immer nur

Additiv.

Okay, aber den Unterschied da genau zu verwenden

ist wahrscheinlich, wie man gerade schon rausgehört hat,

eher vielleicht gar nicht so.

Ja, man findet auch ganz viel

tatsächlich in freier Wildbahn und halt Leute, die irgendwie das halt anders machen, als man das vielleicht tun sollte.

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

Ja, da kommt dann die Response zurück, 402.

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, was halt falsch ist oder

Ja, aber kann auch sein, kann auch sein

Ja, kann auch sein, weil 200 bedeutet ja nur okay, 200 bedeutet ja nur in Ordnung

und Jochen unterhalten sich über die Programmiersprache Python

Ja, das ist so ein Problem.

Auch das ist so ein Problem, wenn man auf 201

wartet und erwartet, dass das Subjekt

zurückgegeben wird,

dann kommt ganz oft

gar nichts zurück und dann schlägt

quasi diese Abfrage fehl, weil

kein Content kommt.

Auch damit habe ich

mich schon abgeplagt.

Ja, ja.

Na gut. Ich verpake mich immer

mit dem 402 ab.

und was war das nochmal?

Payment required.

Payment required, ja.

Reserved for future.

Nee, der wichtigste ist doch 418.

Ja, T-Pod war das, oder?

Armer T-Pod, ja.

Ja, genau.

Also ich meine, tatsächlich in der Praxis

funktioniert es meistens ja eigentlich ganz gut.

Man kann sich da irgendwie durchwurschteln

und dann geht es schon.

Und genau.

Tatsächlich ist aber auch,

dann gibt es ja so,

und

Doktorarbeit. 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 nicht schon.

Auch sehr interessant.

Die Dissertation fängt an

und endet jeweils mit einem Zitat von

na, wie heißt er noch?

Der Architekt mit den

Entwurfsmustern.

mit den Entwurfsmustern

mit den 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 eine etwas komische Abkürzung

dass sozusagen

Hypermedia as the Engine of

...

Genau.

Moment, wie war das?

HatoS.

HatoS, genau.

ApplicationState, genau.

Hypermedia as the Engine of ApplicationState, genau.

Richtig. Das 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 sich nachholen.

Weil das hätte ich genau wissen müssen.

Sollte man sich nochmal diese...

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 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 Single-Page-App

Aber die Single-Page-Apps,

die es so gibt, die sind eigentlich so gar nicht

REST

Und die sind auch, was das Hypermedia-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

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

Single-Page ist eigentlich auch ein falter Name, aber

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

Also wenn man nicht sehr viel Arbeit macht, meinst du

Weil gute

SPAs haben natürlich

Ja klar, Server-Side-Rendering

und den internen Zustand,

wo du auch Deep Links machen kannst auf SPAs.

Aber das ist nicht so

gängig, um es mal so zu sagen.

Was ist jetzt ein Deep Link wieder?

Wenn du so eine SPA aufrufst,

dann bist du ja auf

spa.io

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

und Jochen unterhalten sich über die Programmiersprache Python

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, dass du zum einen

Links machen kannst auf

Objekte, also

API slash

Spreadsheet

spreadsheetid

table

cell

row17, irgendwie sowas.

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

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. 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 bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm bestimm

hat es einmal geklappt, aber ansonsten

also irgendwelche Applikationen,

die ihr UI dadurch

aufbauen, dass die irgendwie

aus einer API irgendwie

ihre Formulare bekommen und das

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.

Alles zur Laufzeit wird das zusammengebaut.

Ja, also ich meine, es wäre natürlich schön,

also der Vorteil, den du halt hast, wenn du das 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.

Ja.

auch ungeheuer schwierig, das zu machen,

weil die Interna verändern

sich ja auch. Also ich meine,

wir können auch gerne mal noch ein

Stündchen über API-Versionierung sprechen,

weil auch da geht es 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 zu machen.

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 mit der Version oder so,

keine Ahnung, die anderen müssen hier 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 es dann einfach

ignorieren und dann sagt, oh, das ist für mich nicht interessant.

Also wie bei HTML ist es ja auch so,

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 automatisch Vorwärts-Compatibility,

je nachdem, wie man das sehen möchte.

Ja.

Also irgendwie, also

die Idee ist irgendwie voll cool, aber

ehrlich gesagt, ich weiß nicht so richtig. Ich bin mal

gespannt. Also bei

jetzt HTML und Web hat es ja eigentlich mal

geklappt, aber ob das

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 so was

wie zum Beispiel, also eigentlich

das sind schon nette Ideen, also das

HTTPS-Dateless 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

darauf so oft machen, wie du willst. Kannst du so oft machen, wie du

willst, voll gut. Das Problem ist nur,

so inzwischen ist halt

TLS,

HTTPS ist halt überall.

Sollte man auch nicht mehr ohne

machen. Ja.

und damit wird das mit der Cachebarkeit und so, das ist halt dann alles so ein bisschen für die Tonne, weil, ja gut, der Browser selber kann es noch Cachen, aber so, dass da irgendwo Der Server kann es Cachen.

Der Server kann es Cachen, der Client kann es Cachen, aber dazwischen kann es nicht.

Und ja, damit hat das nicht mehr so eine riesig große Relevanz und das war ja auch in die, ja, das sieht man jetzt auch heute ja, die ganzen, so, ja, Phoenix Live View,

bei Ripple und Melz gibt es das mit Stimulus und

diese ganzen Hotwire-Geschichten. In anderen

Frameworks kommt das jetzt auch, dass man wieder HTML über WebSockers 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 HTTP stateless ist, muss da halt immer

irgendwie alles mitgeschickt werden,

weil, naja, ist ja stateless.

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

Genau, und das

ist eigentlich total

ineffizient auch, hätte ich gesagt.

Und deswegen gehen halt dann viele Richtung,

ja, nehmen wir doch einfach WebSocket oder so,

da ist es halt dann nicht mehr stateless.

Ja.

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, 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 Operation

und es sind dann genau sieben Werte oder so etwas, oder genau dieses Objekt und genau dieses Objekt

und das hast du jetzt mit REST ja nicht mehr so einfach, mit REST greifst du ja 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, ich meine,

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

dann da kommt und das je nachdem,

was man halt braucht.

Aber dann hat man im Grunde

keine Restschnellschwelle und dann hat man

irgendwie sowas wie eine Datenbank

Schnittstelle. 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

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

da macht der Client ja schon viel zu viel.

Das hat den Client alles nichts anzugehen,

das muss alles der Server machen.

Da hat der

Client viel zu viel State und

der ist ja, ja,

und das geht ja alles gar nicht.

Ja, aber das ist ja, also ich meine,

das ist ein bisschen unrealistisch.

Gegen Regen argumentieren.

Es ist schlecht, dass es Regen gibt

und der fällt aus dem Himmel runter

und der macht alles nass, aber es ist halt so.

Ja, ja.

Das gibt es halt

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

Da hilft mir aller Rest Purismus nichts

weil das müsste dann irgendwie abdecken

Es gibt auch Fälle

Sagen wir mal so, um es positiv zu formulieren, für manche Anwendungsfälle braucht es ein bisschen Umdenken von diesem Prozeduraldenken.

Wir als Programmierer haben ja oft so ein prozedurales Denken. Ich möchte, dass jetzt irgendwas passiert und deshalb 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 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 folgender Empfänger ist

und deren folgender Text ist

und deren Absendedatum

gerade jetzt ist.

das erfordert ein gewisses Umdenken,

wenn es eben was inhärent

Aktives ist, was passiert.

Bei Nachrichten schicken ist es schon,

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 steuert, wenn ich

und Jochen unterhalten sich über die Programmiersprache Python

Das ist so ein bisschen, ja...

Es erfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordfordford

anschalten

Wunschobjekt oder irgendwie sowas.

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,

worauf es hinausläuft, die grundsätzlichen

Operationen, die man tun kann, sind halt

das ist mal, ich weiß nicht, das hatten wir bestimmt auch schon mal

ein paar Mal erwähnt oder so, ist halt CRUD.

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 darauf mappen.

Es geht sogar halbwegs elegant, also oft ist es tatsächlich so, dass es auf den tatsächlichen Anwendungsfall eigentlich ganz gut, also oft passt es einfach ganz gut und man ist eigentlich dann zufrieden.

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

aber prinzipiell

ja

das ist auch immer etwas was man

es gibt schon so Sachen

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

ich schicke ein Bild an eine

Bilderkennungs-API dann ist es für mich nicht

ich möchte dass es

und Jochen unterhalten sich über die Programmiersprache Python

Prozedurale.

Ein Funktionsobjekt

mit folgenden Parametern wurde angelegt.

Ja, das ist natürlich

irgendwie... Also ja, nee,

es gibt Dinge, die da nicht so gut reinpassen.

Ich weiß gerade so was wie,

wenn man jetzt Blobs hat, eben Bilder oder so was.

Da

ist es sowieso schwierig.

Genau.

Ist ja auch dann ganz schwierig.

Das kriegst du ja auch nicht per Get.

Natürlich.

natürlich. Du kriegst es auf jeden Fall nicht mehr bei JSON.

Du musst dann halt, wenn du so ByteRange

verpasst, ob du irgendwelche Blobs machst, dann...

Moment, wenn du über ByteRange denkst,

also ein Blob ist irgendwie eine Art Dateiobjekt

oder sowas. Ja, also zum Beispiel

so was wie eine Podcast-Episode. Ein Binary Large Object.

Ja.

Also eine Podcast-Episode und du willst jetzt

eine Minute drei anfangen zu h weil da beginnt der interessante Teil REST Aber das ist ja tats bei REST nicht

vorgegeben, welche Daten

Strukturen du verwendest, sondern ganz im Gegenteil.

Jeder Request soll ja immer einen

Media Type haben und dann halt

kannst du es in verschiedenen Sachen abrufen.

Also REST ist gar nicht nur JSON.

Nee, nee, kann auch was anderes.

Kann auch XML sein.

Wenn du willst.

Hurra!

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

Schnellstellen 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.

Du kannst verschiedene

Media Types anfordern.

Und auch Juggeress Framework stellt ja durch diese

Serializer, die man normalerweise hat,

das ist wie das Formular, was man

sonst so kennt. Genau, der stellt

dieses Formular zur Verfügung, der stellt auch

den JSON-Datentyp zur Verfügung,

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 ein 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 Blob-Objekt wäre es

halt dann

Application

Binary, weiß ich nicht.

Octet.

Ja, ja, ja.

Nee, stimmt schon. Also insofern würde das da auch reinpassen.

Ganz kurz nochmal, Octet-Stream,

was ist das denn?

Ja, Octet ist der coolere Name

für Byte. Also es sind einfach

Binärdaten, die übertragen werden.

Also zwei hoch...

Das ist so der Fallback-Type.

Wenn ich nicht weiß,

was es ist, dann sind es halt irgendwie Binärdaten.

Und das heißt, als MIME-Typ oder als

Datentyp heißt es Application

slash OctetStream. Heißt einfach nur

irgendwelche Daten, keine Ahnung.

Okay, OctetStream.

Auch gerade jetzt zum ersten Mal drüber gestolpert, das ist ja Wahnsinn.

Wie lange macht man das eigentlich schon?

Ich weiß es nicht.

zu lange.

Also ja, okay,

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.

Dann gibt das auch REST, oder?

Options ist WeGet nur ohne Inhalt.

Das ist nur, wenn man sozusagen die Header abrufen möchte,

um zum Beispiel die Datentypen

rauszufinden oder die verfügbaren Datentypen rauszufinden.

Das heißt, man kann quasi nach Options fragen

und dann bekommt man alle Optionen, die

Datentypen bereichern.

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 2-Stunden-Episode ist, also eine von den kurzen.

Geradezu mickrig, kurzen.

Meine Frau hat sich vorhin darüber lustig gemacht, dass wir so lange eine Episode aufnehmen, aber ich habe ihr 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 ein Options-Request

hin und dann sagt mir der Server halt, ja, der hat

so und so viel 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 Arpies

Rest-Arpies 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

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,

mag daran liegen, dass das super ist, aber auch, dass es halt

einfach, dass man da dann

anfängt, in einem etwas interessanteren Markt zu sein,

weil das, was man sonst

so sieht, also

wenn du,

keine Ahnung, also das, was halt so,

gibt es ja 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.

Das ist halt irgendwie Low Budget.

Die Kunden sind üblicherweise nicht bereit, da so wahnsinnig viel Geld auszugeben.

Ja, es war früher ein besserer Markt.

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

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

Es ist meistens irgendwelche, naja, doch eher so technisch herausgeforderte.

Kommt dann über die Add-ons, glaube ich, wenn du dann noch ein Magento dran machen kannst, dann bist du wieder...

Genau, dann kannst du natürlich 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 viel richtig Wert hin und es ist auch noch schwierig.

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

während wenn du halt

dann sowas machst wie Django REST Framework

oder so, da ist

plötzlich irgendwie, da ist richtig Wert drin

wenn da irgendwie die Apps von Leuten

richtig gut funktionieren

da suchen Leute

händeringend, 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.

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

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 Realtime API Support

using WebSockets.

Ja, dann mit

Django Channels in Zusammenhang.

Better Authentication by Default.

Also die wollen vielleicht sogar Jot

und Core Support in das Core Package

reinbringen, wo wir eben schon kurz

sprachen. Das klingt doch ganz interessant.

Was war das?

Wo wir gerade...

Dominik,

ich habe gleich noch eine

kleine Randnotiz.

Was war das für eine Authentifizierung?

Genau, was war das für eine Authentifizierung?

.JWT.

Ah, echt?

JSON Web Token.

Aber da gibt es ja Bibliotheken.

Also ich meine, das ist ja nur

ein PIP-Install entfernt.

Ja, aber da gibt es halt verschiedene

nicht so gute

Varianten.

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, dass...

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 über diese Token zu erzeugen.

Weil es so viele Konfigurationen gibt.

Weil du sozusagen so

Soundgrade-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 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.

Das kannst du machen.

Du musst dann deinen Server so

konfigurieren, dass der die Sachen nicht annimmt,

aber es ist relativ schwierig herauszufinden,

was jetzt gerade alles schon unsicher ist.

Also das heißt,

es geht darum, welche 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.

Und der Server ist so eingestellt,

dass er auch die unsignierten annimmt, dann nimmt er halt

auch die unsignierten an. 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, naja,

Verschlüsselung, naja, kann ich nicht.

Das ist eben

wirklich so, die

die Frage, was ist jetzt gerade der aktuelle Zustand der Sicherheit?

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

Ja, und ich weiß nur mal, so ganz im Detail kann ich es nicht.

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

Und JVT, also von ihm, gab es irgendwie einen Post auf der Django-Mailing-Liste von James Bennett, glaube ich,

wo er mehr oder weniger klipp und klar gesagt hat, JVT werden wir in Django niemals machen.

Das ist irgendwie...

Jott?

Hm?

Jott?

Was ist das?

Dominik, du bist der Einzige, der Jot sagt.

Ich habe das im Blogpost gelesen von Toni, der das schrieb.

Ah, okay.

Vielleicht ist das richtig, ich weiß es nicht.

Schöne Grüße.

Ich sage immer Jason Webtoon.

Jason Webtoon.

Ich sage immer Jason Webtoon.

Genau, jedenfalls ist da die Ansage so,

das Protokoll ist scheiße, das machen wir nicht.

Was ist denn die Alternative, Jochen?

Das ist halt die offizielle Alternative,

jedenfalls,

so wie es in dem offiziellen

Django-Podcast, Django-Chat

von Carlton Gibson,

der offiziellen Django-Maintenner,

der übrigens ein total netter Kerl ist.

Der ist total nett, ja.

Sometimes pronounced Jot,

sagt Wikipedia. Sometimes pronounced.

Sometimes.

Ich versuche es dann mal jedes dritte Mal zu machen.

Genau, der sagt halt...

und Jochen unterhalten sich über die Programmiersprache Python

Aber auch nicht so arg, ganz ehrlich.

Ja, aber wenn man doch,

also ja, wenn man

irgendwie kann, das was man in Python

macht, kann die Dot-Bibliothek nicht einfach sagen,

nee, ich bin nicht downgradebar, also ist das

nicht da schon mit drin, also das muss ja dann,

der Standard kann das vielleicht,

aber wenn jetzt meine 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, dann...

Ja, dann bist du inkompatibel.

Dann sagen die Clients, mit der Api

kann ich nicht reden, kaputt.

Ja, gut, kann ja sein.

Aber den kleinen, den kann ich ja quasi selber sagen.

Kannst du machen, Dominik.

Kannst du machen.

Dann kann man dabei bleiben, dann muss man nicht sagen, oh nein.

Ja, aber wenn ich den kleinen selber ausliefer, 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 du ja nicht viel gewonnen.

Außer, dass du jetzt selber immer die Authentifizierung

in jeden Request reintun musst, weil der Browser

das nicht automatisch macht.

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

Ja.

Ja.

Dann kann ja jemand so tun, dass wer ja meine Session

klauen will oder sowas und dann...

Ja, kann er machen.

Das verhindert der Browser.

Ja, aber egal.

Es ist kompliziert.

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

Ich bin überrascht, ich habe mich da schon ein paar Mal Gedanken gemacht und ich war immer überrascht, dass es da keine eigene fertige Antwort gibt.

Die wenig gelöst ist.

Sondern dass man immer denkt, oh, ich habe die Antwort gefunden und dann irgendwie ein paar Monate, Jahre später kommt einer um die Ecke und sagt, was machst du denn da, das ist doch totaler Quatsch.

Und das passt man einem 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.

Ja, okay, ja, okay, Authentifizierung

über REST.

Es ist erstaunlich ungelöst.

Ja, REST ist ja erst mal

nur eine ganz normale HTTP-Webseite.

Also du kannst Authentifizierung machen mit allen Mechanismen,

die du da hast.

Ich meine, wir haben auch

früher alle die Webseiten gesehen,

die die PHP-Session-It

als

Get-Parameter drin hatten.

Du durftest mal halt nicht kopieren.

Dann dürfen wir halt die Links nicht verschicken

Ja

Wie macht man denn sonst noch

REST-APIs mit Python?

Genau, also ja

General REST-Fanwork, schöne Sache

Ich glaube in der

Flask, ich weiß gar nicht mehr

wie man das ausspricht, vielleicht spricht man das auch J aus

Nein, Flask

Ich weiß es nicht genau

Flask-K

Flask-K

Jason

Genau, da verwendet man eher Marshmallow, das gibt es auch für Django, aber da verwendet man meistens Django REST Framework

Ist so ähnlich

Was ist das jetzt wieder, Marshmallow?

Das ist auch eine Bibliothek, so ähnlich wie Django REST Framework, aber im Grunde, ja

Endpunkte

Benutzt man ja noch Flask, Jochen

Ja, aber genau, da wäre Hot Take

Ich würde dir sagen

So, jetzt habe ich ja

was ganz gemeines.

Jetzt machst du die Tore

für Flameworks.

Der einzige Grund,

Flask noch zu verwenden, ist ja so im Grunde,

aus meiner Perspektive, ich kenne mich auch nicht wirklich mit Flask aus,

aber wenn man alte Python-Versionen

hat, weil

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 dann nicht sowas wie Flask-API?

Also

Meinungen.

Wenn ich nicht nur eine API schreiben werde.

Hallo at pythonpodcast.de.

Da könnt ihr gerne Kommentare und

Afterlame an Jochen und

Kommentare jederzeit erwünscht hinterlassen.

Machen wir mal so eine Episode, wo wir die

vorlesen einfach.

Ja, das Problem ist, die ist dann

aber keine zwei Stunden lang.

Ja, außerdem wollen wir ja nicht

ja, es sind ja immer viele

nette Nachrichten da.

Es gibt ein sehr schönes Buch von einem

Science-Fiction-Autor, das heißt

Your Hate Mail Will Be Graded.

wo er einfach

Fanpost

sagen wir es mal in Anführungszeichen

die an ihn geschickt wurde

diskutiert

und

sowas

Jochen du wirst jetzt sicherlich

jetzt wurde es gesagt

das umfasst ja auch alle anderen

alternativen

alle anderen alternativen Systeme

CherryPie

Pyramid

Repose, Soap

Es gab ja eine neue Version

Pyramid 2.0, voll gut

Ich weiß es ehrlich gesagt gar nicht so genau, was

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, ist das nicht auch?

Aber das ist super, ja, Bottle gibt es

ist super klein

Ja, das ist kleiner als Flask, 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 es Fast macht, mehr oder weniger

Hat auch im Vergleich zu Flask

mehr Stars bei GitHub, auf jeden Fall als Bottle

Na super

Ja, aber das ist doch

Fast API ist doch wirklich nur für APIs gedacht, oder?

Ne, du kannst

du kannst

ja, ist gedacht, aber

es geht auch anders, du kannst da einfach

Ginger 2 Templates verwenden

und die Dinger ausliefern, gar kein Problem, geht

und

genau, du musst halt alles

Starlet ist halt sozusagen das

Ding da drunter

die Werbung ist on par

with Node.js and Go

ja

das besprechen wir

in der Benchmark

war das für

einen Benchmark der legal war?

ja, okay

Aber du hast halt, also 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 und gut für

Alle Leute, die sich damit nicht abfinden wollen, können auch bitte an

welche E-Mail-Adresse schreiben.

Hallo, at Python Podcast.

Def 0 at Python.

mal.

Aber ich finde die Syntax ist halt

besser. Du hast halt da, das ist halt

nativ Async, direkt alles.

Die ganzen Geschichten

sind halt,

du könntest ja auch quasi in Django

oder halt in den Serializern Sachen mit

Type-Annotationen halt sozusagen da

die Typen festlegen oder so.

Geht nur nicht, weil das ist halt älter als

Type-Annotationen, deswegen musste man sich da schon was anderes überlegen.

In Django mit den Descriptoren.

Aber

in FastAPI ist halt erst ab Python 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,

naja, das sind wir auch schon

eher beim Restthema,

ein Frontend, das aber nicht

so wie bei Django REST Framework so ein eingebautes

gerendertes Ding ist, sondern

das ist 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 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

Jungle REST Framework.

Und das sieht eigentlich sehr gut aus.

Ja, sieht echt gut aus. Und das ist übrigens auch von Sebastian Ramirez,

der auch Typer gemacht hat.

Den hatten wir auch schon mal kurz ein, zwei Mal erwähnt.

Das sind schon interessante Sachen.

Da gab es doch noch was von dem einen, der

Jagerest Framework gemacht hat, wie hieß das denn gleich noch?

Ja, das ist ja

Tom, na,

wie heißt er noch?

Tom Christie, genau

Der hat auch

Starlet gemacht

Ah, ist das Starlet?

Wie hieß dieses, das hieß

Star API oder irgendwie sowas?

Fast API, meinst du?

Nee, dieser Standard, den er da sich ausgedacht hat

Ach, ich weiß es nicht mehr

Ach ja, das gab es auch. Er hat auch ein API-Ding gemacht.

Jaja, aber

ja, ob das...

Das war nur sehr kurzlebig, oder?

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

Es waren auch coole Ideen dabei.

Da war zum Beispiel sowas dabei, wie dass du dann auch gleich

Kommando-Zahlen-Interface kriegst und so.

Aber irgendwie...

Was ist denn jetzt da?

Das wäre auch schon wieder

Superschwung.

Das ist das, was Fast-API drunter

verwendet.

Das ist quasi von einem Delphi-Entwickler, der

Dango S-Film gemacht hat und das hat dann

Fast API-Benutzung.

Cool.

Also Tom Christie macht eine Menge coole Sachen.

Der hat

einen Nachfolger von

Request Bibliothek.

HTTPX.

Genau, hat so ein bisschen ein Problem.

Und zwar einmal ist sie so

slightly unmaintained.

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 an Sync wird, dann will man vielleicht auch so

Async-HTTP-Requests machen.

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.

Das geht halt nicht mit Async-Io oder so, so einfach.

Ja, und HTTPS

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 es so verwenden, wie man es gewohnt ist.

Man verwendet einfach

HTTPX anstelle von Requests.

Auch sein Nennt. Aber tatsächlich

irgendwie ein bisschen langsam

manchmal, ich weiß nicht so genau.

Ich verwechsel es immer mit

HTMX.

Das ist eine JavaScript-Bibliothek,

die Elemente

interaktiv macht.

Kann man sich auch mal ansehen.

Aber ich verwechsel es immer.

Ja, genau, also ja

das sind so, ich weiß nicht

ob ihr jetzt noch, also das ist eben Marshmallow,

Django REST Framework,

FastAPI mit

Saga Pydantic, also man kann dieses Saga Interface auch bei

anderen APIs, man kann das auch mit Django REST Framework verwenden

das machen ja auch viele

bei Marshmallow geht das bestimmt auch

ich weiß nicht, gibt es da sonst noch Dinge?

Ja, das ist doch das, was jetzt OpenAI, also dieses OpenAI API

Ja, ja, genau

Ja

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

ums jetzt mal sozusagen, 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 ist Facebook,

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-Objektkonventionen 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 Graph-förmige Daten,

ja auch gerade, ich meine,

da passt halt auch normales SQL, man kann 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 ja immer bei SQL, ist ja immer Sicherheit

Wir haben das gelacht, ihr habt das kurz drüber gesehen

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, weil das ist für die Entwickler

genau das, was die Entwickler haben wollen

nur hast du damit halt

Sicherheit kannst du vergessen

hast keine Sicherheitsabfragen

mit SQL kannst du alles machen

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ß gar nicht, ob die EdgeDB Leute

noch eine eigene Sprache da haben

oder ob die auch GraphQL

Was ist EdgeDB?

Das sind eigentlich im Grunde

die Leute hinter Python

hinter der ganzen

Python Async-Geschichte

hinter Async.io und so

die machen

ein Ding namens

HDB und

ja, es 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, dass

es vielleicht eventuell eine Konkurrenz zu GraphQL

oder so, ich weiß nicht genau

vielleicht auch nicht.

Vielleicht nochmal ganz kurz zu dem Unterschied, also was REST jetzt macht

ist Objekte und damit kann man wunderbar

Quad machen und das eignet sich super für

normales SQL.

Und GraphQL, nein,

falsch. Ne, 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 unterschiedliche

URLs machen, die dann unterschiedliche Sachen liefern, aber

du kannst halt jetzt nicht

das wäre halt nicht restkomfortabel

eigentlich, genau, hat jedes

Objekt Invest 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 es

eigentlich gar nicht gibt und das ist schon so.

Gar nicht REST.

Eigentlich soll das nicht so sein.

Also ich sollte alle Abfragen einzeln machen, um zu gucken,

ob die hier drin sind und dann alle wieder wegschmeißen,

die es nicht sind.

Nee, das 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 Hatoas drin ist.

Weil die nirgendwo verlinkt sein kann.

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

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

Deswegen nennt man auch Hyper-Synergizer beim Dango REST Framework.

Hyperlink-Synergizer, genau.

Genau, damit die Links alle korrekt drin sind, damit du draufklicken kannst.

Das ist eigentlich einer der Grundsätze, dass du sozusagen den AP-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 nirgendwo verlinkt

die musst du kennen

und das ist schlecht

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

in den Options

kriegst du eigentlich die Header zurück.

Da kriegst du eigentlich die Header zurück und dann müsstest du dir

wieder irgendwelche

Header überlegen, die auch nicht

standardkonform sind,

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,

dass du die Dokumentation mitlieferst, kannst

dir die Dokumentation anschreiben.

In einem Swagger-File

weiß ich gar nicht, wie das abgebildet werden würde.

und Jochen unterhalten sich über die Programmiersprache Python

und Grafiel 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 bitte folgende Abfrage aus

Du hast halt auch nicht eine URL für die unterstrichen Geschichten, sondern du hast halt eine URL, an die alles geht und es gibt nicht mehr Delete, Pad, Putsch

Push.

Der mächtigste

aller

Aber auch