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

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.

Ja, wen frage ich denn zuerst?

Was ist denn das?

Ich dachte, wir wollen nicht vielleicht zuerst die 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.

Kommen wir nicht mehr zu den News?

Doch, die kommen noch zu den News.

Na gut, okay.

Erklär mal ganz kurz, was REST ist.

Aber nur ganz kurz.

Ja, das ist Elevator-Picture.

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

Na ja, 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.

Kurz vorm der Anleitung.

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.

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 suchen wir jetzt Objekt News ab.

Jetzt machen wir News?

Ja, jetzt machen wir News. Gut, okay, machen wir

News.

Pattern Matching!

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 habe sogar, 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 Switch Case?

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 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 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 3, dann ist es ein Stereo.

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 zu kompliziert wird

und ich meine, da gab es ja auch diese große

Kontroverse irgendwie beim

Walrus Operator.

Ja.

Auch bei den Typen, bei dem

Type Automation.

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.

Und dann kann man da zwei verschiedene Typen haben.

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,

diese Type Annotations, die

sind halt an manchen Stellen total nett.

Ob ich das jetzt an allen Stellen

im Kult gerne hätte, weiß ich jetzt auch nicht.

Du kannst ja einfach weglassen, das wäre das Schöne. Genau, genau.

Ja, man kann es dann, genau.

Und da, wo es halt Sinn macht, irgendwie,

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 auch häufiger, irgendwie

entweder Dataclasses

Adress oder

Pidentic verwenden

und tatsächlich Klassen so

hinzuschreiben, ist deutlich angenehmer

als das irgendwie...

Hatten wir Pydentik schon mal?

Ich weiß nicht genau, ob ich es mal

gepickt hatte oder so, kann sein.

Was macht Pydentik?

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

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 ein paar Identity in der Doku mal rumgewühlt.

Also eigentlich wollte ich wissen, was das ist, aber

Ja, das ist so

eine Art Mischung aus

MyPi 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 das 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-Geschichten? Was ist

das denn, Jochen? Ja, Moment.

Erstmal die Reste der News, bitte.

Genau.

Was haben wir denn

da noch? Ja, so

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

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

Ja, 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 Wrapper um LibUV und das ist eine super schnelle Abstraktion über die ganzen Betriebssystem-spezifischen Schnittstellen, sowas wie EPOL oder KQ oder was weiß ich nicht, was da sonst so.

TCP-Completion-Ports oder

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

Ich denke, auf Datenbank stelle ich mich 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.

Ja, aber das ist ja okay. Du hast 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 ein...

an die Datenbank und dann blockierst du halt

einen Code.

Das ändert nicht

die Datenbank, Dominik, sondern es ändert nur,

wie du die Verbindung der Datenbank hältst.

Aber

wo wir gerade bei PsychoPG sind,

PsychoPG3 ist angekündigt.

Die koordinieren sich gerade

mit den Django-Leuten,

dass die Datenbank-Verbindungen 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

klar, oder ich dachte, das passiert irgendwie magisch automatisch

und das passierte nicht, wenn man ein Thread aufmacht,

dann

macht das eine zweite 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, dann kriegt man Ärger

von dem Datenbank-Admin, weil

der sagt, meine ganzen Connections

dazu, was zur Hölle macht ihr denn da?

Ja.

Ups. Ups, genau.

Ja.

Ja, ja, aber Pooling wäre auf jeden Fall

eine schöne Geschichte, weil manchmal ist ja auch

eine Verbindung nicht genug und

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

Es gab einen Artikel zu...

Es gab da schon ein paar Artikel zu, das stimmt.

Ja, und das...

Dependency-Conclusion. Ja, sehr deprimierendes

Problem, ehrlich gesagt. Das musst du gerade erklären.

Was ist Dependency Confusion?

Ja, da gab es doch so ein, da hat auch 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. Oder wenn sie sich vertippen, genau.

Dann kann man das sozusagen

hijacken und dann kann man den Software

installieren, die auch im

großen Grenzen 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 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.

Also, und hat da auch

überall irgendwie quasi das... Ja, okay, das

habe ich auch gehört. Diese Preisgelder

dafür gekriegt, die man halt für...

Millionenweise. Ja.

Also das war, das hat sich gelohnt.

Ja, auf jeden Fall.

Und das ist auch wirklich ein fieses Problem

und es gibt eigentlich nicht so, es ist

so ein bisschen doof. Also Poetry

könnte doch da helfen, oder? Wenn ich jetzt irgendwie die Hashes

von den Dependencies da mit... Nee, leider nicht.

Nee, nein? Nee, hilft nix, weil

du ja immer noch den Namen eingeben musst

irgendwann. Ja, aber wenn

das bei einer Pi-Project-Humil schon gepinnt ist,

richtig, dann

hoffe ich mal, dass du die richtige

gepinnt hast. Beim ersten Mal muss ich

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

siehst du es nie wieder.

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

Toastcode 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ß, was da drin ist. Das Problem haben wir auch bei Distributionen,

aber jetzt, wenn man jetzt eine Distribution

nimmt und man installiert per

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

Die können 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 du 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 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 das ist doch Quatsch.

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.

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

C-O-R-S? 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.

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-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 da drüber alles abrufen.

Oh.

Und das ist, ja,

genau so habe ich auch reagiert.

Das war mir jetzt nicht klar. Oh, shit.

Aha.

Oh.

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.

Prinzipiell kannst du eine Verbindung irgendwo hin aufmachen

und sagen, ja, 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,

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

irgendwie wie nein.

Das ist, 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 zu 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ückbringen konnte, wenn ihr denn

mit den News schon soweit seid. Ja, das ist nicht mehr viel.

Es ist noch ein,

tatsächlich jetzt, das 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 so was.

Letzte? Ich weiß nicht mehr genau.

Also tatsächlich. Da müssen wir 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.

Mit 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, 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 seiner Geburtstage, die man bisher gehabt hätte, deutlich unter diesen Tagen gewesen wäre.

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

Mit welcher Formierung habe ich mich gerettet?

Die Zahl der gefeierten Geburtstage,

das ist leider,

ist meine Goldwaage, sagt ja.

Ja.

Tja, ja. Ja, gut.

Genau, aber dann, ach so, doch, eine Geschichte

habe ich noch. Genau, du hattest mir,

Johannes, du hattest mir, glaube 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 der 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 hatte etwas

gebenchmarked. Jemand hat irgendwas gebenchmarked, genau.

Und das Einzige, was ich dazu im Grunde

nur anmerken wollte, also

also

mit so einem

Körnchen Salz

sollte man da vielleicht schon

mit dazu tun, sonst

Also du sagst,

man müsste das mal selber machen.

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, ne halt, warte

Benchmark. Ne, aber ich glaube, das ist

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 Peißen die schnellste Sprache ist unter der Sonne?

Ne, aber vielleicht schnell genug.

Wir wollen beweisen, wie die schnellste,

wie man damit schnell sein kann.

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, wenn man sich diesen Artikel

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 man sich es dann so anguckt,

wie wenn da so

HTTP-Doodles oder

bei Scenic ist das dann installiert, bei dem anderen nicht

und HTTP-Parsing kann ja dann das Nadelöhr...

Also ich will gar nicht

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, ist klar. Gut, dann

Geschichte einander mal.

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

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 man mehr

Bandbreite, also dass wir

ein Netzwerk

sinnvoll benutzen hätten können.

Das war das mit dem Gigabit, was du nicht kriegst

ausgelastet.

Was war die erste Zahl,

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

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

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

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,

hm, 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 Nginx 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

angeteasert, aber genau. In der Benchmark-Episode.

Ja.

Genau. Wir wollten übrigens noch so eine

Datentypen-Folge machen. Die haben wir auch noch aufgeschoben.

Nur für alle, die sich darüber freuen. Ja, eine Datentypen-Folge.

Ja.

Ja, okay.

Ja, ist eine spannende Sache.

Gibt's viele schöne Dinge.

Ich hab noch was zum Thema Web-Server.

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

es auszuprobieren, aber ich werde, habe mir

vorgenommen, es 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

Lincoln Group, der auch dieses

High-Performance-Django-Buch,

der hat das, glaube ich, geschrieben

und der hat auch so ein Ding

gebaut. Auch so, 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, ja,

es ist doch eher so Ruby-and-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 dann halt jetzt auch sowas gebaut, nämlich

das nennt sich Up-Pack-IO

und ist halt auch im Grunde sowas wie

Heroku. Also sozusagen, du kannst dein 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.

Es ist spannend, dass es so viele Firmen

im indischen Ozean gibt. Das ist schon sehr cool.

IO ist indischer Ozean.

Achso.

Ja, hat der

indische Ozean ausnahmsweise

mal was richtig gemacht mit der Wahl

des Top-Level-Winners.

Ja, Glück gehabt.

Glück gehabt.

Pack IO, sagst du.

Jochen, du abtustenst den Link ja sicherlich.

Genau, Up-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 Reste übrig.

Das ist nur noch der Rest. Da müssen wir jetzt über die Reste

reden. Ja.

Also, wo waren wir eben stehen geblieben,

Johannes?

Ja, als im Vergleich zu

Remote Procedure Call.

Weil, also ich meine, Remote Procedure

Magical, 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 dem Java-XML-RPC, 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. 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üher 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 ü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,

wenn dann nicht die richtige Version

von dieser API lief.

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,

ich war nicht dabei,

aber ich denke,

dass das eben der Grund war,

warum man zu REST-APIs

ist oder eine 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 REST-Seite, den man

an so Sachen wie Soap oder auch

Sachen, wo dann andere Leute versucht haben, Korba

irgendwie zu retten in die neue

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 ihr das Web

dazu zu degradieren, dass das nur ein Transport

Layer ist für eure Idee, die

auch schon vorher eigentlich nicht funktioniert

hat. Also was heißt Korba

in die Webwelt?

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

Das ist die Object Management Group.

Und genau.

Ich hatte viel Spaß mit Cobra.

Schon.

Und ja,

das war

auch alles nicht schön.

Das klang

alles nach einer guten Idee.

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

Ja, 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 Handvoll. 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?

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

eine Version

änderst, dann puttest 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. 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

ein neues und wenn du auf eine

Ja, so ganz klar ist es.

Okay, ja, ehrlich

gesagt, weiß ich auch nicht genau. 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 auf jeden Fall. 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 ist, 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 kann das, hat es schon zwei

Bedeutung. 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 auch, 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 brauche ich mir ums Löschen

von Adre, von Adrecken 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. 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 sicherlich

auch hier ganz viele Kommentare kriegen,

dass wir alle Idioten sind und dass es nur eine

wahre Lösung gibt.

Ja, da kommt

ein Response zurück, 4.02.

Nee, 2.01 kommt dann zurück.

2.01 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

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

Ah gut.

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.

Okay, okay, okay, gut, ja, also es ist, okay, ja.

ja. Auch 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 diese,

schlägt quasi diese Abfrage fehl, weil du, weil

kein Content kommt.

Ach je. Auch das, auch damit

habe ich mich schon abgeplagt.

Ja, ja.

Na gut. Ich verplage mich immer mit dem 402

ab.

Was war das nochmal? Kein Geld bezahlt?

Payment required.

Payment required, ja.

Reserved for future use.

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,

da gibt es ja so,

und 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

eine der Hauptverantwortlichen

hinter dem Web hat,

steckt halt auch hinter dieser Rest-

Idee, ne, Roy Fielding,

hat da seine Dissertation drüber geschrieben,

ja genau, 2005 ist sie glaube ich erschienen,

und da

genau, kann man

sich angucken, gibt es online, auch als Webseite.

Sehr schön.

Oh, auch sehr interessant.

Link, please. Ja, genau, Link kommt in die

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

Der mit 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 eine etwas komische Abkürzung, dass sozusagen Hypermedia is the engine of, genau, Moment, wie war das?

Hey to us. Hey to us, genau. Application state, genau. Hypermedia is the engine of application state, 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 wissen.

Wenn man das wirklich genau wissen will, 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 einen wichtigen 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, Stau, Stau

auf der Datenautobahn. Das macht das

Web halt irgendwie kaputt. Das macht es halt

nicht so, also so eine

Single-Page, ja ich meine Single-Page ist eigentlich

auch ein falter 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... Also wenn man nicht sehr viel Arbeit

macht, meinst du.

Weil gute SPAs haben

natürlich 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.

Ja, aber was ist jetzt ein Deep Link wieder?

Ja, wenn du so eine SPA aufrufst,

dann bist du ja jetzt nochmal 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 die eben,

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

einen Links machen kannst

auf Objekte.

Also API

Slash Spreadsheet

Slash

Spreadsheet ID Slash Table

Slash

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, ja?

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 geht. 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 bestimmten Parametern

oder so, kannst du halt auch nicht drauf verlinken.

Das ist 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 Webfall 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

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.

Ja. Also.

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 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 Leute mit alten

Client-Anwendungen

halt auch deine neue

Geschichten benutzen können und du sozusagen

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 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 hat nämlich jeder von uns

eine Meinung dazu.

Und ich weiß auch mindestens drei

verschiedene Wege, wie man das machen kann.

Aber

ja, das

ich kenne quasi keinen Fall, wo

es sich lohnen würde, verschiedene API-Versionen

gleichzeitig laufen zu haben, was

ja sehr teuer ist erst mal.

Ja.

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 wird das dann einfach ignorieren

und 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 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 sowas wie zum Beispiel, also eigentlich, das sind schon nette Ideen.

Also das HTTP-Stateless ist ja eigentlich cool,

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

Und kannst du auch 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 zu Recht auch.

Ja, genau. 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. Ja, alles dazwischen 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 & Wells gibt es das,

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 dem

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 ja nicht,

weißt ja nicht, was der schon hat oder nicht. Genau.

Und das

das ist eigentlich total ineffizient

auch, ehrlich gesagt. Und

deswegen gehen halt dann viele Richtung, ja,

nehmen wir doch einfach WebSocket oder so, da haben wir

dann, das ist halt dann nicht mehr Sadness.

Ja.

Ja, das ist aber auch so eine der,

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 irgendwie sowas. Oder genau diese

Subjekte und genau diese Subjekte.

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 Teil

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

ja 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 denn dann da kommt

und das je nachdem, was man halt braucht.

Ja, aber dann hat man im Grunde eben keine Restschnittstelle

und dann hält 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, GraphQL.

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 dem Client alles nichts anzugehen,

das muss alles der Server machen.

Das ist ja nicht,

da hat der Client viel zu viel State

Und das geht ja alles gar nicht.

Ja, aber das ist ein bisschen unrealistisch.

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

Es ist nicht schwer, sich vorzustellen,

dass es Leute gibt, die ihren Freunden Nachrichten schicken wollen.

Sondern schon brauche ich eine Liste der Leute,

denen ich Nachrichten schicken kann.

Und 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, ja, ich möchte, dass jetzt irgendwas

passiert und deshalb schreibe ich

diese, rufe ich diese Funktion auf, ja.

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, ja, 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, ja, dann sage ich nicht, schicke diese Nachricht an, ja, sondern es, sage ich, 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.

Und 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 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 REST-Schnittstelle,

dann heißt das, ich

bearbeite das Lichtaktivierungsobjekt

und setze das Attribut an

auf, ja, anstatt dass ich sage,

mach das Licht an.

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.

Ein Kontrollvorgang, dem steht Licht an oder Licht aus.

Ja, genau, wo du dann eben sagst,

wo man sich so ein bisschen behilft, ja,

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,

das ist mal, ich weiß nicht,

das hatten wir bestimmt auch schon 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 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.

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

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% RESTful machen,

die dann auch so eine Schnittstelle eben als REST-Schnittstelle 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, ich meine, es gibt Dinge, die

da nicht so gut reinpassen, wo man dann auch nicht,

gerade bei sowas wie, wenn man jetzt Blobs hat, eben

Bilder oder sowas,

da ist sowieso

schwierig da irgendwie, genau.

Ist ja auch

dann ganz schwierig, das kriegst du ja auch nicht

per Get, so, also das

natürlich, du kriegst

auf jeden Fall nicht mehr bei JSON. Du musst dann halt, wenn du

ByteRange pressst, ob du irgendwelche Blobs machst, dann

da gibt's... Moment, wenn du über ByteRange

denkst, dann irgendwelche Blobs. Also ein Blob ist irgendwie eine Art

Datei-Objekt 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 an Minute 30

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

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.

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 das war so eine Offenbarung,

dass so was geht

und dann so schön die Schnellen 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, ja?

Genau, der stellt dieses Formular

zur Verfügung, der stellt auch den JSON-Datentyp

zur Verfügung, 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

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

ja, Application

irgendwie ein binäres Name. Binary.

Weiß ich nicht. Octet. Octet-Stream.

Ja.

Ja, ja, ja. Nee, stimmt schon. Also insofern

würde das da auch reinpassen. Ja.

Ganz kurz nochmal. Octet-Stream. Was ist das denn?

Ja, Octet ist ein cooler,

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 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, wie er zum ersten Mal drüber gestolpert hat, das ist ja Wahnsinn.

Wie lange macht er das eigentlich schon? Ich weiß es nicht.

Zu lange.

Also ja, okay, dein 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? Geht das auch REST oder?

Options ist wie Get 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.

Ja, 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 Zwei-Stunden-Episode ist, also eine von den kurzen, dann …

Geradezu mickrig, kurzen.

Meine Frau hat sich vorhin drüber lustig gemacht,

dass wir immer so lange eine Episode aufnehmen.

Aber ich habe gesagt, das ist halt so.

Dann möchte ich eben nicht

die gesamte,

möchte ich nicht diese ganze

Episode auf einmal abrufen, sondern ich möchte erst mal

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

viel Bytes und

der Content-Type ist so und so.

Und dann kann ich sozusagen

ausprobieren, ob die

ob diese Anfrage sinnvoll ist.

Ja, okay.

Interessant.

Aber um jetzt wieder zu

REST-APIs 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, 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,

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

was man sonst so sieht, also

naja, wenn du

irgendwie, keine Ahnung, also das, was halt so

gibt es ja viele, viele, die

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 für

auszugeben, weil es gibt so wahnsinnig...

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 irgendwie es ist

einfach nicht so geil. Es ist meistens

irgendwelche, naja,

doch eher so technisch herausgeforderte

Hoster. Das 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 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 viel richtig Wert

hin und es ist auch noch

schwierig. Das ist einfach ein unangenehmer

Ort. Während,

würde ich jetzt mal so sagen,

wenn du halt

dann sowas machst wie die Django REST Framework oder so,

da ist plötzlich

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 mehr Wert,

wenn das halt gut funktioniert und man ein

nettes Interface hat, wo man die API

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

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 ja eben schon kurz sprachen.

Das klingt doch ganz interessant.

Was war das?

Django REST Framework.

Dominik, erzähl mal,

ich habe gleich noch eine

kleine Randnotiz.

Was war das für eine Authentifizierung?

Jot JWT.

Ah, echt?

Ja, das ist Java JSON Web Tokens.

JSON Web Tokens?

Aber da gibt es ja Bibliotheken.

Also ich meine, das ist ja nur ein PIP-Installed entfernt.

Ja, aber da gibt es ja 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 ...

Ja, aber die Frage ist, warum der Standard nicht okay ist.

Wenn ich das richtig verstanden habe,

weil es verschiedene Möglichkeiten gibt,

diese Schlüssel zu erzeugen oder überhaupt diese Token zu erzeugen.

Weil es so viele 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.