Cooles Video. Gute Redensart. Sehr verständlich erklärt. Danke. Aber was ist mit PATCH für das Ressource Update? Als kleiner Tipp: wenn du auf die Tafel schaust, dann hört man dich schlechter, da das Mikrofon zur Kamera zeigt. Vielleicht wäre es besser ein Mikrofon am Mund zu haben. Das bietet volle Bewegungsfreiheit.
Danke für den Hinweis. Ich hatte ein Funkmikro verwendet, dieses aber links befestigt. Mit nach rechts gedrehtem Kopf ist es dann zu leise. Wir werden auf jeden Fall am Ton und an der Rechtschreibung arbeiten.
Interessantes, kurzes Video über ein Thema, dass ich bisher gar nicht als Frage wahrgenommen hatte. Trotzdem würde ich es nochmal neu drehen, denn /cieties statt /cities hat mich doch etwas abgelenkt :)
cooles Video. Zu 03:50: Ein Autoinkrement für die IDs zu verwenden scheint mir aus security-gründen nicht sinnvoll zu sein, sonst könnten die Ressourcen erraten werden. UUID ist aus meiner Sicht die bessere Lösung zu sein.
Sehr schönes Video und gut erklärt. Ich mag deine klare und deutliche Aussprache. Nur eine kurze Frage: was für Fragen wurden euch denn gestellt bezüglich der PUT/POST Problematik? Für meine internen privaten APIs, die nur ich selbst nutze mit einem Backend, was keine Unterscheidung zwischen dem erstellen einer Ressource bzw deren Bearbeitung macht (ist eine id im Model gegeben entsteht ein Update, ist keine id gegeben wird neu angelegt [Yii2]) lasse ich daher sowohl mit Post als auch mit Put beides zu. Wieso hatten eure Kunden so oft Probleme damit? Letztlich ist es doch recht einfach, gibt es den Datensatz nicht, wird er erstellt, ansonsten bearbeitet. Würde mich mal stark interessieren. Danke fürs Feedback
In deiner API, die du für dich nutzt kannst du deine Lösung einsetzen. Mir gefällt, dass die Aufrufe "wiederholbar" sind. Dazu gleich mehr. Interessant finde ich den Ansatz, beides POST und PUT zuzulassen. Ohne die Frage POST versus PUT wäre REST sicher einfacher. Unsere Kunden hatten folgende Probleme oder Anforderungen: I. Fehlende Transaktionen bei APIs Der wesentliche Unterschied von PUT ist, die Wiederholbarkeit. Ein PUT signalisiert dem Nutzer einer Schnittstelle, dass er im Fehlerfall die Anfrage ohne Nebenwirkungen wiederholen kann. Ein POST signalisiert, dass ein Aufrufer bei einem wiederholten Aufruf riskiert, dass es zu unerwünschten Effekten wie z.B. einem Duplikat kommen kann. Siehe 1:45 im Video. Da HTTP statuslos ist und keine Transaktionen unterstützt, kann ich so zumindest einen Teil der Fehler ausgleichen. III. API als Plattform Eine Schnittstelle für einen größeren Kreis von Entwicklern sollte einfach zu verwenden sein, und keine Überraschungen bieten. Die meisten Entwickler erwarten einen POST für Anlegen und ein PUT für Ändern. III. Konformität zu HTTP und den REST Prinzipien Die entscheidende Stelle findet sich in Abschnitt 4.3.4. PUT im RFC 7231: "The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation. The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics, whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. Hence, the intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server." Siehe 0:57 bis 1:14 und 2:57 bis 3:23
5:42 "... weil das viele Entwickler dann nicht verstehen" Ja, das sind diese Entwickler vom Schlage "Haben wir schon immer so gemacht". Ich hab noch nie was mit REST/PUT/POST gemacht und verstehe es eigentlich sofort. Und ich würde mich nicht mit einer technisch unzureichenden Lösung zufriedengeben, wenn es so einfach ist, es besser zu machen.
Ist die Frage nach POST/PUT/GET nicht immer der verzweifelte Versuch REST eine Art von Standard anzuheften? Ob und wie man jetzt etwas adressiert oder mehrfach triggern und ggf. einen retry oder rollback auslösen kann, ist doch am Ende (leider eh) vom implementierten Backend und Dev abhängig.
Super erklärt und hab gleich geliked und abonniert. 😁 Bin Tester und hab keine Ahnung von der Entwicklung und gleich eine Frage zum Post-Problematik (2:20). Man kann doch hier im Anschluss von POST/cieties/ gleich ein Request mit 201l/cities/1 abschicken, ob da was zurück kommt. Wenn ja, dann weiß ich doch, dass es geklappt hat mit dem neuen Eintrag. 🙄 Oder habe ich da zu einfach gedacht? 😁
Hi Piano_Dreamer C_Moll. Solltest du eine Antwort auf HTTP Ebene bekommen, dann weißt du, ob es geklappt hat (201) oder nicht (400,500). Wenn der POST allerdings mit einem Timeout abbricht, weißt du nicht, ob das vor oder nach dem Erzeugen passiert ist. Du hast auch keine URI oder ID über die du abfragen kannst, da diese vom Server vergeben wird. Du könntest dir die ganze Liste geben lassen und darin suchen. Für einen Test könnte das Ok sein, in der Praxis kostet das aber Ressourcen und ist nicht einfach umzusetzen. Beim PUT dagegen kannst du bei einem Netzwerkfehler die Aktion einfach wiederholen.
Sehr gut erklärt, ich war in diesem Bereich etwas unsicher, danke für die klaren Worte.
Danke für dein Feedback
Danke für diese tolle, leicht verständliche Erklärung.
Cooles Video. Gute Redensart. Sehr verständlich erklärt. Danke.
Aber was ist mit PATCH für das Ressource Update?
Als kleiner Tipp: wenn du auf die Tafel schaust, dann hört man dich schlechter, da das Mikrofon zur Kamera zeigt. Vielleicht wäre es besser ein Mikrofon am Mund zu haben. Das bietet volle Bewegungsfreiheit.
Danke für den Hinweis. Ich hatte ein Funkmikro verwendet, dieses aber links befestigt. Mit nach rechts gedrehtem Kopf ist es dann zu leise. Wir werden auf jeden Fall am Ton und an der Rechtschreibung arbeiten.
Interessantes, kurzes Video über ein Thema, dass ich bisher gar nicht als Frage wahrgenommen hatte.
Trotzdem würde ich es nochmal neu drehen, denn /cieties statt /cities hat mich doch etwas abgelenkt :)
Danke für den Hinweis. Da sollte ich was tun.
Ach was! Das war immerhin konsequent. ;-)
man kann Variablen/Pages etc. nennen wie man will ;-)
Super Video, vielen Dank!
Tolle Erklärung
cooles Video. Zu 03:50: Ein Autoinkrement für die IDs zu verwenden scheint mir aus security-gründen nicht sinnvoll zu sein, sonst könnten die Ressourcen erraten werden. UUID ist aus meiner Sicht die bessere Lösung zu sein.
Vielen Dank wirklich Qualitatives Video, bitte weiter so. Haben Sie auch Patron?
Patreon haben wir nicht. Wir bieten aber zu einigen Videos Zusatzmaterial auf unserer Homepage an. Im Video ist dann ein Link in der Beschreibung.
Toll erläutert. Danke.
Sehr schönes Video und gut erklärt. Ich mag deine klare und deutliche Aussprache. Nur eine kurze Frage: was für Fragen wurden euch denn gestellt bezüglich der PUT/POST Problematik?
Für meine internen privaten APIs, die nur ich selbst nutze mit einem Backend, was keine Unterscheidung zwischen dem erstellen einer Ressource bzw deren Bearbeitung macht (ist eine id im Model gegeben entsteht ein Update, ist keine id gegeben wird neu angelegt [Yii2]) lasse ich daher sowohl mit Post als auch mit Put beides zu.
Wieso hatten eure Kunden so oft Probleme damit? Letztlich ist es doch recht einfach, gibt es den Datensatz nicht, wird er erstellt, ansonsten bearbeitet. Würde mich mal stark interessieren. Danke fürs Feedback
In deiner API, die du für dich nutzt kannst du deine Lösung einsetzen. Mir gefällt, dass die Aufrufe "wiederholbar" sind. Dazu gleich mehr. Interessant finde ich den Ansatz, beides POST und PUT zuzulassen. Ohne die Frage POST versus PUT wäre REST sicher einfacher.
Unsere Kunden hatten folgende Probleme oder Anforderungen:
I. Fehlende Transaktionen bei APIs
Der wesentliche Unterschied von PUT ist, die Wiederholbarkeit. Ein PUT signalisiert dem Nutzer einer Schnittstelle, dass er im Fehlerfall die Anfrage ohne Nebenwirkungen wiederholen kann. Ein POST signalisiert, dass ein Aufrufer bei einem wiederholten Aufruf riskiert, dass es zu unerwünschten Effekten wie z.B. einem Duplikat kommen kann. Siehe 1:45 im Video. Da HTTP statuslos ist und keine Transaktionen unterstützt, kann ich so zumindest einen Teil der Fehler ausgleichen.
III. API als Plattform
Eine Schnittstelle für einen größeren Kreis von Entwicklern sollte einfach zu verwenden sein, und keine Überraschungen bieten. Die meisten Entwickler erwarten einen POST für Anlegen und ein PUT für Ändern.
III. Konformität zu HTTP und den REST Prinzipien
Die entscheidende Stelle findet sich in Abschnitt 4.3.4. PUT im RFC 7231:
"The fundamental difference between the POST and PUT methods is
highlighted by the different intent for the enclosed representation.
The target resource in a POST request is intended to handle the
enclosed representation according to the resource's own semantics,
whereas the enclosed representation in a PUT request is defined as
replacing the state of the target resource. Hence, the intent of PUT
is idempotent and visible to intermediaries, even though the exact
effect is only known by the origin server."
Siehe 0:57 bis 1:14 und
2:57 bis 3:23
direkt abonniert, cooles video
5:42 "... weil das viele Entwickler dann nicht verstehen" Ja, das sind diese Entwickler vom Schlage "Haben wir schon immer so gemacht". Ich hab noch nie was mit REST/PUT/POST gemacht und verstehe es eigentlich sofort. Und ich würde mich nicht mit einer technisch unzureichenden Lösung zufriedengeben, wenn es so einfach ist, es besser zu machen.
Ist die Frage nach POST/PUT/GET nicht immer der verzweifelte Versuch REST eine Art von Standard anzuheften? Ob und wie man jetzt etwas adressiert oder mehrfach triggern und ggf. einen retry oder rollback auslösen kann, ist doch am Ende (leider eh) vom implementierten Backend und Dev abhängig.
Spell check: failed.
Cities.
Good explanation though
Super erklärt und hab gleich geliked und abonniert. 😁
Bin Tester und hab keine Ahnung von der Entwicklung und gleich eine Frage zum Post-Problematik (2:20). Man kann doch hier im Anschluss von POST/cieties/ gleich ein Request mit 201l/cities/1 abschicken, ob da was zurück kommt. Wenn ja, dann weiß ich doch, dass es geklappt hat mit dem neuen Eintrag. 🙄 Oder habe ich da zu einfach gedacht? 😁
Hi Piano_Dreamer C_Moll. Solltest du eine Antwort auf HTTP Ebene bekommen, dann weißt du, ob es geklappt hat (201) oder nicht (400,500). Wenn der POST allerdings mit einem Timeout abbricht, weißt du nicht, ob das vor oder nach dem Erzeugen passiert ist. Du hast auch keine URI oder ID über die du abfragen kannst, da diese vom Server vergeben wird. Du könntest dir die ganze Liste geben lassen und darin suchen. Für einen Test könnte das Ok sein, in der Praxis kostet das aber Ressourcen und ist nicht einfach umzusetzen. Beim PUT dagegen kannst du bei einem Netzwerkfehler die Aktion einfach wiederholen.
@@predic8 verstehe und danke für deine Erklärung - hab was wieder dazu gelernt 😁👍
cities schreibt man aber ohne e
Hallo danke sehr schön erklärt, allerdings ist der Ton sehr leise
Danke für den Hinweis. Am Ton muss ich noch arbeiten.
Cieties? Oder doch eher cities?