Vielen Dank für das Stellen der Frage, wenn du wissen willst was Mocken ist und wo der Unterschied zwischen Mock, Dummy, Stub und Spy ist, dann schau dir mein Video dazu an ua-cam.com/video/IVjATZTSZzM/v-deo.html
Guten Abend Vitalij, Ich habe oft festgestellt, dass es gar nicht so schwer oder kompliziert ist, wenn man was "grösseres" entwickeln möchte :) Und auch eine REST-API ist gar nicht so kompliziert, wie es zum einen anhört. Vielen herzlichen Dank für dein Video und deine Erklährung dazu. Mit besten Grüssen Jan
ja fast alle MicroFrameworks eignen sich super dafür. Leider haben die MicroFrameworks kein vernüftiges DI Managment so dass man selbst die Klassenstrukturen zusammenbauen muss. Wenn ich mit Slim Arbiete baue ich immer den PHP-DI Bridge da ein.
@@VitalijMik Guter Punkt, das hatte ich auch vermisst. Das Skeleton könnte da aber einen guten Ansatz bieten, war mir bisher für meinen Anwenungsbereich von ein paar Routen aber schon zu viel des Guten.
Hey wieder ein super Video. Kannst du mal was machen zu git oder versionierung? Und den Arbeitsablauf Workflow mit git (gitflow). Vielleicht eins über die Grundlagen und einen über den workflow. Wie machst du das wenn du features für jemanden einbringen sollst. Arbeitest du dann da am live system oder machst du dafür vom live system eine kopie und baust da deine features ein. Deine Videos sind echt gut :)
Hallo Vitalij vielen Dank für deine tollen Videos! Ab Oktober 2022 wird es nur noch über das Protokoll OAuth2 möglich sein auf Exchange-Server, oder sonstige Ressourcen von Microsoft mit einer selbst programmierten Webanwendung zu zugreifen. Ich habe recherchiert und es gibt derzeit kein Video das zeigt, wie man eine PHP Seite baut, die man zuvor bei Azure AD registriert, die dann letzten Endes die Berechtigung bekommt von einer E-Mail-Adresse, welche einen MS Exchange-Server nutzt, E-Mails vom Posteingang abzurufen. Muss man dazu MS Graph API nutzen, oder geht das auch ohne? Ich bin überzeugt, dass es spätestens im Oktober viele Programmierer geben wird, die ihre Webanwendung auf OAuth2-Autorisierung umbauen müssen. Ein Video dazu von dir wäre top!
Uff das ist aber was ganz spezielles. Ich bin sicher dass du dazu kein Video finden wirst. wenn man generell oauth versteht dann sollte es kein Problem sein daten von den APIs anzufragen.
ich glaube nicht dass die JWT wirklich sicher ist, damit dann ein Authentification Prozess zu erstellen halte ich nicht für Sinnvoll. Ich kann höchstens ein TUtorial machen wie man Public Daten aus der Session, die sowieso jeder sehen DARF, dann an weitere Server weiterreichen mit JWT.
@@VitalijMikweil ich eine Authentizierung machen wollte für meine Anwendung mit REST, aber leider weis ich nicht wie ich vorgehen soll. Ich dachte das JWT gut wär. Ich würde mich freuen wenn du ein Tutorial zu REST mit Auth machen würdest.
@Vitalij Mik: Zitat: "Ich würde mich freuen wenn du ein Tutorial zu REST mit Auth machen würdest" --> Ja, das wünsch ich mir auch. --> würde mir dabei github.com/AHaDaHA/henkashop ziemlich helfen. 😉😁
Hi Vitalij, super Video, bis auf die URLs. Was du als REST beschreibst ist eigentlich einfach nur das nutzen von HTTP. Es gibt verschiedene Level von REST (0 - 3) und du beschreibst so ein Mittelding zwischen Level 0 und 1. Mehr über diese Level kann man auf Martin Fowlers Blog lesen ( www.martinfowler.com/articles/richardsonMaturityModel.html ). In REST ist es so, dass die URLs einem Schema folgen. Dabei "zeigt" die Route auf die Resource, die angesprochen werden soll und die Resource sollte in der Mehrzahl geschrieben sein: also statt _/todoItem_ schreibt man /todoItems. In deinem Beispiel wird dem Server über die URL (todoItem/create, todoItem/update) die Methode mitgegeben. Das wird in REST vermieden, da die URL im besten Fall auf Resourcen zeigen soll. Statt den Methoden in der URL wird mit den HTTP Methoden wie GET, POST, PUT, DELETE ausgedrückt, was mit der Resource gemacht werden soll: _GET /todoItems_ würde alle todoItems lesen _GET /todoItems/{id}_ würde ein todoItem mit der angegebenen id lesen _POST /todoItems_ würde ein neues todoItem erstellen _PUT /todoItems/{id}_ würde ein todoItem mit der angegebenen id überschreiben _DELETE /todoItems/{id}_ würde ein todoItem mit der angegebenen id löschen
Hey Danke für die Korrektur, dann ist es halt so dass die Praxis von der Theorie abweicht, es halt sich nur wenige an diese Beschreibung, in meisten Fällen wird zwischen "Rest" und "Restful" unterschieden. Bisher war es üblich dass ich meistens nur POST und GET Requests versenden sollte. Werde beim nächsten Mal mir mehr Zeit zum Recherchieren um auf die Theorie dahinter einzugehen.
Hier ein Beispiel aus der Praxis: developer.twitter.com/en/docs/twitter-api/v1/tweets/post-and-engage/overview nach der gängingen Definition bezeichnen wir solch eine API als "REST API" und wenn man sich zum Beispiel Paypal anschaut dann wäre das eine "RESTFul API"
@@VitalijMik "dann ist es halt so dass die Praxis von der Theorie abweicht, es halt sich nur wenige an diese Beschreibung" das stimmt, macht es aber leider nicht besser :) "Bisher war es üblich dass ich meistens nur POST und GET Requests versenden sollte." Dafür gibt es einen einfachen Grund, es gibt in php keine $_PUT/$_DELETE SuperGlobal und $_GET/$_POST sind nicht so ganz gut von der Namensgebung her, was es etwas schwieriger für nicht so erfahrene User macht. In Roman seinem Beitrag siehst du ja das es lediglich eine Route (/todoItems/{id}) gibt, welche du jedoch mit 3 verschiedenen Methoden ansteuern kannst (GET/PUT/DELETE), für GET hast du wie gewohnt deine $_GET SuperGlobal. PUT/DELETE darfst du in php halt erstmal nach der Server Request Methode schauen $_SERVER['REQUEST_METHOD'], bei einem DELETE ist der request body meist nicht wichtig für dich und du parst keine Daten sonder dich juckt nur URL Route welche gelöscht werden soll, bei einem PUT request sieht das anders aus und du liest den php://input stream aus. Wenn du nun z.B. eine GUI hast von der du einen PUT/DELETE senden willst, wirst du sehr häufig sehen das der Request per POST geschickt wird aber dann ein hidden field mit der Methode angeben ist damit man sich gar nicht erst damit befassen muss ob der genutze Browser diese Methoden versteht.
Hey Vitalij, sehr schönes Video. Auch, dass Du gezielt Code vermieden hast befürworte ich für so eine Art Video. Man kann, ich nenne es mal, "einfache" PHP-Anwendungen, wie Gästebuch oder Blog sofort in eine Todo-Liste umwandeln. Das gilt streng genommen für alle. :D
@@VitalijMik natürlich, da gebe ich dir recht. Sobald aber bspw. media:image oder media:statistic genutzt wird, wird es schon komplizierter, oder ich mache es mir nur kompliziert ^^ PeerTube nutzt dies sehr viel.
Das essentielle an einer REST Schnittstelle hat nix mit Routen zu tun. CRUD ist was komplett anderes. Das Video fing gut and und mixt dann mal wieder alle Themen zusammen.
Das Problem war wohl dass eine TODO App so klein ist dass da REST und CRUD hat gleich gesetzt ist. Bei einer TODO App kann ich halt nicht sooo viele weiteren Routen definieren, ich hätte vielleicht die eine Route wie etwa /view/statistics oder so erwähnen sollen, bei dem man tracken konnte wie schnell TODOs abgearbeitet werden oder so. ALso quasi etwas anderes neben einfachem CRUD
Ja du könntest den Server der die Daten verteilt mit PHP programmieren und die Oberfäche dann mit Javascript. Bekannte PHP Spiele wäre zb www.die-staemme.de/ www.herozerogame.com/ www.sfgame.de/ www.travian.com/ damit du halt sehen kannst was man so machen kann
habe ich, ich habe einen Router Tutorial erstellt, alles was du nun machen musst, ist es in routen die daten aus der datenbank auszulesen und ein JSON response zu generieren. Mehr ist es nicht
Wieso eigentlich nicht gleich mit einer API beginnen, und HTML über JSON bauen lassen... 🤔🤔🤔 Interessant. Ich muss mir den callback zu file_get_contents() mal näher ansehen mir steht curl nicht zur Verfügung.
Was meinst du mit HTML über JSON bauen lassen? Meinst du im JavaScript alles rendern? Eine API hat nicht für jede Applikation einen Sinn. Und du musst schauen wo du dann überall deine Tests schreibst. Wenn du 50% PHP und 50% JS hast, dann musst du im JS auch deine komplette Testpyramide umsetzen, was auch Aufwand bedeutet.
@@VitalijMik Ich hab nur laut über ein momentanes Projekt nachgedacht. Ja, das ist ein guter Hinweis. Natürlich muss alles durchgetestet werden. JS das Ganze im Client rendern zu lassen würde in meinem speziellen Fall total Sinn ergebeben. Vielleicht sollte ich mir aber trotzdem auch noch node.js ansehen.
@@JoPhiGURU es ist egal ob NodeJs oder PHP. Wenn du eine Mächtige Applikation im Front-End hast, kommst du nicht drumherum Unittests und Implementation Tests im Front-End zu erstellen und das gleiche auch im Backend damit die API auch richtige Daten liefert. Egal ob NodeJS oder PHP. Weil ich meistens die Projekte alleine umsetze, erspare ich mir die Arbeit und mache alles im Backend, damit der Front-end eigentlich nichts zu tun hat. Wenn man allerdings nur ein prototype baut ohne den tests ist es in der tat wurscht und zum experementieren kann man es ja dann nutzen.
Vielen Dank für das Stellen der Frage, wenn du wissen willst was Mocken ist und wo der Unterschied zwischen Mock, Dummy, Stub und Spy ist, dann schau dir mein Video dazu an ua-cam.com/video/IVjATZTSZzM/v-deo.html
Guten Abend Vitalij,
Ich habe oft festgestellt, dass es gar nicht so schwer oder kompliziert ist, wenn man was "grösseres" entwickeln möchte :)
Und auch eine REST-API ist gar nicht so kompliziert, wie es zum einen anhört.
Vielen herzlichen Dank für dein Video und deine Erklährung dazu.
Mit besten Grüssen
Jan
Haha so gut wie jedes mal wenn ich irgendeine frage zu php bei yt eingeb bist du da :D eherenmamnn
bei über 300 Videos kein Wunder :D
Moin, auch hier wieder sehr cool erklärt. Mal sehen wie ich damit in der Praxis zurecht komme. BG
Dankeschön wegen Praxis. Schau dir mein Router Video an vielleicht wird es klarer
@@VitalijMik I'll I'll do that too ;)
Habe ich gerade zufällig für eine Headless App gemacht, und dafür Slim Framework benutzt. Finde den Ansatz von Slim dafür super.
ja fast alle MicroFrameworks eignen sich super dafür. Leider haben die MicroFrameworks kein vernüftiges DI Managment so dass man selbst die Klassenstrukturen zusammenbauen muss. Wenn ich mit Slim Arbiete baue ich immer den PHP-DI Bridge da ein.
@@VitalijMik Guter Punkt, das hatte ich auch vermisst. Das Skeleton könnte da aber einen guten Ansatz bieten, war mir bisher für meinen Anwenungsbereich von ein paar Routen aber schon zu viel des Guten.
Klasse...danke
Besten Dank. Schön erklärt :)
Wahrscheinlich wusstest du das aber eh schon :D
Trotzdem lernt man ja nie aus ;-)
Hey wieder ein super Video.
Kannst du mal was machen zu git oder versionierung? Und den Arbeitsablauf Workflow mit git (gitflow). Vielleicht eins über die Grundlagen und einen über den workflow. Wie machst du das wenn du features für jemanden einbringen sollst. Arbeitest du dann da am live system oder machst du dafür vom live system eine kopie und baust da deine features ein. Deine Videos sind echt gut :)
Hey danke für das Kommentar, war auch geplannt dass ich das mache, aber aktuell fehlt mir die Zeit dazu, kann nur kurze Videos bringen.
würde mich auch interessieren
Hallo Vitalij vielen Dank für deine tollen Videos! Ab Oktober 2022 wird es nur noch über das Protokoll OAuth2 möglich sein auf Exchange-Server, oder sonstige Ressourcen von Microsoft mit einer selbst programmierten Webanwendung zu zugreifen. Ich habe recherchiert und es gibt derzeit kein Video das zeigt, wie man eine PHP Seite baut, die man zuvor bei Azure AD registriert, die dann letzten Endes die Berechtigung bekommt von einer E-Mail-Adresse, welche einen MS Exchange-Server nutzt, E-Mails vom Posteingang abzurufen. Muss man dazu MS Graph API nutzen, oder geht das auch ohne? Ich bin überzeugt, dass es spätestens im Oktober viele Programmierer geben wird, die ihre Webanwendung auf OAuth2-Autorisierung umbauen müssen. Ein Video dazu von dir wäre top!
Uff das ist aber was ganz spezielles. Ich bin sicher dass du dazu kein Video finden wirst. wenn man generell oauth versteht dann sollte es kein Problem sein daten von den APIs anzufragen.
Kannst du auch zeigen wie man eine JWT Auth macht?
Ich finde deine Tutorials / Videos sehr gut. Weiter soo
ich glaube nicht dass die JWT wirklich sicher ist, damit dann ein Authentification Prozess zu erstellen halte ich nicht für Sinnvoll. Ich kann höchstens ein TUtorial machen wie man Public Daten aus der Session, die sowieso jeder sehen DARF, dann an weitere Server weiterreichen mit JWT.
@@VitalijMikweil ich eine Authentizierung machen wollte für meine Anwendung mit REST, aber leider weis ich nicht wie ich vorgehen soll.
Ich dachte das JWT gut wär.
Ich würde mich freuen wenn du ein Tutorial zu REST mit Auth machen würdest.
@Vitalij Mik: Zitat: "Ich würde mich freuen wenn du ein Tutorial zu REST mit Auth machen würdest" --> Ja, das wünsch ich mir auch. -->
würde mir dabei github.com/AHaDaHA/henkashop ziemlich helfen. 😉😁
Hi Vitalij,
super Video, bis auf die URLs. Was du als REST beschreibst ist eigentlich einfach nur das nutzen von HTTP. Es gibt verschiedene Level von REST (0 - 3) und du beschreibst so ein Mittelding zwischen Level 0 und 1. Mehr über diese Level kann man auf Martin Fowlers Blog lesen ( www.martinfowler.com/articles/richardsonMaturityModel.html ).
In REST ist es so, dass die URLs einem Schema folgen. Dabei "zeigt" die Route auf die Resource, die angesprochen werden soll und die Resource sollte in der Mehrzahl geschrieben sein: also statt _/todoItem_ schreibt man /todoItems.
In deinem Beispiel wird dem Server über die URL (todoItem/create, todoItem/update) die Methode mitgegeben. Das wird in REST vermieden, da die URL im besten Fall auf Resourcen zeigen soll. Statt den Methoden in der URL wird mit den HTTP Methoden wie GET, POST, PUT, DELETE ausgedrückt, was mit der Resource gemacht werden soll:
_GET /todoItems_ würde alle todoItems lesen
_GET /todoItems/{id}_ würde ein todoItem mit der angegebenen id lesen
_POST /todoItems_ würde ein neues todoItem erstellen
_PUT /todoItems/{id}_ würde ein todoItem mit der angegebenen id überschreiben
_DELETE /todoItems/{id}_ würde ein todoItem mit der angegebenen id löschen
Hey Danke für die Korrektur,
dann ist es halt so dass die Praxis von der Theorie abweicht, es halt sich nur wenige an diese Beschreibung, in meisten Fällen wird zwischen "Rest" und "Restful" unterschieden.
Bisher war es üblich dass ich meistens nur POST und GET Requests versenden sollte.
Werde beim nächsten Mal mir mehr Zeit zum Recherchieren um auf die Theorie dahinter einzugehen.
Hier ein Beispiel aus der Praxis:
developer.twitter.com/en/docs/twitter-api/v1/tweets/post-and-engage/overview
nach der gängingen Definition bezeichnen wir solch eine API als "REST API" und wenn man sich zum Beispiel Paypal anschaut dann wäre das eine "RESTFul API"
@@VitalijMik "dann ist es halt so dass die Praxis von der Theorie abweicht, es halt sich nur wenige an diese Beschreibung"
das stimmt, macht es aber leider nicht besser :)
"Bisher war es üblich dass ich meistens nur POST und GET Requests versenden sollte."
Dafür gibt es einen einfachen Grund, es gibt in php keine $_PUT/$_DELETE SuperGlobal und $_GET/$_POST sind nicht so ganz gut von der Namensgebung her, was es etwas schwieriger für nicht so erfahrene User macht. In Roman seinem Beitrag siehst du ja das es lediglich eine Route (/todoItems/{id}) gibt, welche du jedoch mit 3 verschiedenen Methoden ansteuern kannst (GET/PUT/DELETE), für GET hast du wie gewohnt deine $_GET SuperGlobal. PUT/DELETE darfst du in php halt erstmal nach der Server Request Methode schauen $_SERVER['REQUEST_METHOD'], bei einem DELETE ist der request body meist nicht wichtig für dich und du parst keine Daten sonder dich juckt nur URL Route welche gelöscht werden soll, bei einem PUT request sieht das anders aus und du liest den php://input stream aus.
Wenn du nun z.B. eine GUI hast von der du einen PUT/DELETE senden willst, wirst du sehr häufig sehen das der Request per POST geschickt wird aber dann ein hidden field mit der Methode angeben ist damit man sich gar nicht erst damit befassen muss ob der genutze Browser diese Methoden versteht.
@@timm.6875 ich weiß, geht halt aktuell nicht anders, vielleicht eines Tages:D
Hey Vitalij,
sehr schönes Video. Auch, dass Du gezielt Code vermieden hast befürworte ich für so eine Art Video.
Man kann, ich nenne es mal, "einfache" PHP-Anwendungen, wie Gästebuch oder Blog sofort in eine Todo-Liste umwandeln.
Das gilt streng genommen für alle. :D
Hey danke für das Kommentar, aber stellte sich wohl raus dass ich einige Dinge weggelassen habe die durchaus wichtig sind, siehe Kommentare :D
@@VitalijMik Ja, das stimmt schon, aber das sind "Kleinigkeiten" und wohl er unter "Konvention" einzuordnen, denke ich.
Den Kern hat es ja getroffen.
@Easy Mathematics wäre gleich mal eine Idee für ein Bergfest Talk, Theorie vs Praxis :D
@@VitalijMik Joa. Why not? :)
Über RSS Feeds würde ich gerne mehr wissen. Besonders deren Unterschiede. Mit bspw. SimplePie. Wäre eine Idee für dich und eine Hilfe für mich ;)
Mir ist unklar wieso man simplepie brauchst. RSS ist ja nur ein XML Format. PHP hat da schon gute tools wie simplexml
@@VitalijMik natürlich, da gebe ich dir recht. Sobald aber bspw. media:image oder media:statistic genutzt wird, wird es schon komplizierter, oder ich mache es mir nur kompliziert ^^ PeerTube nutzt dies sehr viel.
Ah das sind einfach nur namespaces die kann man auch wunderbar nutzen. Vielleicht mach ich noch ein Tutorial dazu wie man XML mit PHP Manipuliert
@@VitalijMik würde mich freuen, bin im Schleifen Chaos gefangen 😅 Namespace bringt mich schonmal weiter, danke dir.
Das essentielle an einer REST Schnittstelle hat nix mit Routen zu tun. CRUD ist was komplett anderes. Das Video fing gut and und mixt dann mal wieder alle Themen zusammen.
CRUD hat auch nichts mit Routen zu tun, von CRUD habe ich gar nicht gesprochen. Habe veilleicht falsche Beispiele gewählt
Das Problem war wohl dass eine TODO App so klein ist dass da REST und CRUD hat gleich gesetzt ist. Bei einer TODO App kann ich halt nicht sooo viele weiteren Routen definieren, ich hätte vielleicht die eine Route wie etwa /view/statistics oder so erwähnen sollen, bei dem man tracken konnte wie schnell TODOs abgearbeitet werden oder so. ALso quasi etwas anderes neben einfachem CRUD
Tolles Video 😁👍
Weißt du auch zufällig wie man einen Trading Bot mit einer KI programmiert???
LG und Dankeschön für das Video 👍
Ich weiß dass man es in MQL5 macht und nicht in PHP ;)
Nun, ich hoffe Du hast eine ausreichend Starke Grafikkarte, um Deine KI zu trainieren, wenn Du mit neuralen Netzwerken arbeiten möchtest.
Könnte man mit php ein online game Programmieren z.b wie agario oder so
Ja du könntest den Server der die Daten verteilt mit PHP programmieren und die Oberfäche dann mit Javascript.
Bekannte PHP Spiele wäre zb
www.die-staemme.de/
www.herozerogame.com/
www.sfgame.de/
www.travian.com/
damit du halt sehen kannst was man so machen kann
Schade das du uns nicht zeigst wie.
habe ich, ich habe einen Router Tutorial erstellt, alles was du nun machen musst, ist es in routen die daten aus der datenbank auszulesen und ein JSON response zu generieren. Mehr ist es nicht
Wieso eigentlich nicht gleich mit einer API beginnen, und HTML über JSON bauen lassen... 🤔🤔🤔 Interessant. Ich muss mir den callback zu file_get_contents() mal näher ansehen mir steht curl nicht zur Verfügung.
Was meinst du mit HTML über JSON bauen lassen? Meinst du im JavaScript alles rendern? Eine API hat nicht für jede Applikation einen Sinn. Und du musst schauen wo du dann überall deine Tests schreibst. Wenn du 50% PHP und 50% JS hast, dann musst du im JS auch deine komplette Testpyramide umsetzen, was auch Aufwand bedeutet.
@@VitalijMik Ich hab nur laut über ein momentanes Projekt nachgedacht. Ja, das ist ein guter Hinweis. Natürlich muss alles durchgetestet werden. JS das Ganze im Client rendern zu lassen würde in meinem speziellen Fall total Sinn ergebeben. Vielleicht sollte ich mir aber trotzdem auch noch node.js ansehen.
@@JoPhiGURU es ist egal ob NodeJs oder PHP. Wenn du eine Mächtige Applikation im Front-End hast, kommst du nicht drumherum Unittests und Implementation Tests im Front-End zu erstellen und das gleiche auch im Backend damit die API auch richtige Daten liefert. Egal ob NodeJS oder PHP. Weil ich meistens die Projekte alleine umsetze, erspare ich mir die Arbeit und mache alles im Backend, damit der Front-end eigentlich nichts zu tun hat.
Wenn man allerdings nur ein prototype baut ohne den tests ist es in der tat wurscht und zum experementieren kann man es ja dann nutzen.
@@VitalijMik, ita est.
php 🤡
Danke für das Kommentar:p