REST API Erklärung | Was ist RESTFul API Design wirklich?

แชร์
ฝัง
  • เผยแพร่เมื่อ 30 พ.ย. 2024

ความคิดเห็น • 10

  • @freecodefans
    @freecodefans หลายเดือนก่อน

    15:08 Hast du diese Tabelle erstellt? Vielleicht hab ich an anderen Kontext im Kopf, weil ich bin gewohnt das Post und Get beides Daten zum Server senden. Get über die URL und Post irgendwie als Packet (z.B. ein ganzes Formular). Ich vermute das hat hier dann in dem API Kontext ne andere Bedeutung bekommen. Interessant das es hier eine Verständnis-Kollision gibt. Aber eigentlich gefällt mir Verwendung bei dir. Gibt man in einem HTML-Formuar an das mit der Methode GET die Daten an den Server gesendet werden (was unüblich ist, meist wird Post verwendet) dann sind die Daten in der URL sichtbar. Aus sicht des Server ist auch dann das GET - finde ich besser - gut zu verstehen. Esselsbrücke Serber bekommt (get) was. Naja. bisschen anderer Kontext. (hatte nebenhet bissle Schach gespielt :D ... muss wohl nochmal zurückspielen)

  • @freecodefans
    @freecodefans หลายเดือนก่อน

    cool. Woher kommt dien Bezug zur IT? Alles selber oder studiert?

  • @giber555
    @giber555 2 ปีที่แล้ว

    Vielen Dank, sehr hilfreiches Video.

    • @amadeuskueppers
      @amadeuskueppers  2 ปีที่แล้ว

      Vielen Dank für dein Feedback!
      Hast du weitere Fragen oder Themen in diesem Bereich?

  • @sakik3631
    @sakik3631 2 ปีที่แล้ว

    Gutes Video. Habe aber eine Frage dazu. Also kann man sagen, dass wenn man ein Backend schreibt (beispielsweise mit NodeJs), dann schreibt man verschiedene APIs mit denen der Client kommunizieren kann. Beispiel eine Api für die Datenbank und andere APIs für andere Systeme? Also schreibt man mit NodeJS, Python usw. verschiedene APIs oder wie nennt sich das, was man mit Backendsprachen schreibt?

    • @amadeuskueppers
      @amadeuskueppers  2 ปีที่แล้ว +1

      Danke für deine Frage. Wenn ich das richtig verstanden habe, willst du wissen ob du verschiedene API's mit verschiedenen Programmiersprachen kombinieren kannst.
      Falls deine Frage darauf abzielt lautet die Antwort: Ja!
      Beantwortet das deine Frage?
      Darüber hinaus, ist es aber auch extrem wichtig zu verstehen was alles in EINEM Service enthalten sein sollte um nicht unnötig viel über das Netzwerk kommunizieren zu müssen.

    • @pinkeHelga
      @pinkeHelga ปีที่แล้ว

      Meistens baust Du pro Service nur eine API. Der Client will Daten oder etwas steuern. Dazu hat Dein Service eine Schnittstelle, über die alles gesteuert wird. Dem Client ist egal, ob die Daten aus der Datenbank, dem Dateisystem oder von anderen Servern bezogen werden.
      Für ganz andere Aufgaben würdest Du eher einen weiteren, unabhängigen Service schreiben, der wiederum eine API hat.
      Der selbe Service kann aber auch mehrere APIs anbieten, etwa eine JSON- und eine XML-Schnittstelle. Das macht man oft, wenn Drittparteien Deinen Service nutzen sollen, um ihnen mit verschiedenen Möglichkeiten entgegen zu kommen. In einigen Umgebungen ist JSON umständlich, andere tun sich schwer mit XML. So hat man beide Optionen.
      Oder die alte API ist in die Tage gekommen, wird den neuen Anforderungen nicht mehr gerecht, und man schreibt eine neue. Da läßt man aus Kompatibilitätsgründen schon mal die alte parallel bestehen, damit nicht alle Clients sofort umrüsten müssen.
      Denkbar sind natürlich auch Fälle mit einer netzinternen API zwischen Services und verteilten Maschinen und einer anderen für den öffentlichen Zugriff.

    • @amadeuskueppers
      @amadeuskueppers  ปีที่แล้ว

      @pinkehelga5256 danke für die ausführliche Ergänzung!

  • @pogluu
    @pogluu 3 ปีที่แล้ว

    Danke :)

  • @dachdoch1801
    @dachdoch1801 3 ปีที่แล้ว +1

    Super Video, gut erklärt.