APIs 2023: Diese Schnittstellen-Technologien müsst ihr kennen

Finde dein Studium bei der FHDW: www.fhdw.de
Selbst kostenlos Informatik lernen auf meiner Website: bootstrap.academy
Quellen:
www.postman.com/state-of-api/
blog.postman.com/api-protocol...
Kapitel:
00:00 Einleitung
00:49 Informatik studieren
01:45 Überblick
02:21 REST
04:58 Webhooks
07:22 GraphQL
09:09 SOAP
10:45 Websockets
12:13 gRPC
13:08 Schlusswort
* Meine Website mit allen anderen Kanälen und Newsletter *:
the-morpheus.de/
Discord:
the-morpheus.de/discord.html
Unterstützt mich - Danke!:
www.patreon.com/user?u=5322110
www.paypal.me/TheMorpheus

[@BreakerBro]

Du bist für die Bildung in Deutschland unfassbar wichtig! Danke!

[@djangogodbye6338]

Als aller erstes bist du selbst verwantwortlich für deine Bildung und Kenntnisse die du dir in Leben aneignest vorallen in der Informatik da hört man nie auf.

[@BreakerBro]

@@djangogodbye6338 ich sagte doch gar nichts von verantwortlich. Aber ja, so ist es

[@gronkhfp]

Viele Videos sind sehr gut. Leider war sein Video zu den besten VPNs schlecht recherchiert. Gerade als er ProtonMail zum bestellen des VPNs als weitere Anonymitätsschicht vorgestellt hat war ich enttäuscht. Eine Woche später hat MentalOutlaw ein Video darüber gemacht, dass ProtonMail alles andere als anonym ist. Man sollte sich niemals auf eine Quelle verlassen und sich immer an verschiedenen Stellen informieren

[@toshicats5649]

für die ganze 🌎🌍🌏thx !

[@DoctorFr0st]

Sehr gut erklärt. Danke für die Quellen

[@ArneBab]

Danke für die Übersicht!

[@kindergeschichtengenerator]

Danke für dieses tolle und informative Video 👍

[@wasgeht2409]

Bro liefert wieder ab! Danke

[@MrsMegaVideo]

Ich hab mich hobbymäßig angefangen mit Apis zu beschäftigen und das Video gibt einem einen echt guten Überblick über den Dschungel der Schnittstellen :)

[@matthias_0815]

Sehr geiles Video, danke

[@Timongcraft]

Und danke für deinen Content, mach weiter so!

[@lx6381]

sehr geiles video. ich studiere informatik und für mich ist das alles nichts neues, aber sehr nice noch mal so ne "zusammenfassung" zu bekommen.

[@Bloome_BlueFolf]

Interessantes, kurz gehaltenes Video mit den wichtigsten Informationen.

[@zweieckiger]

Hey du bist einfach mein lieblings KZbinr und dank dir lerne ich aktuell sehr viel über Web Development was ich grade lerne ❤

[@TheMorpheusTutorials]

Vielen Dank!

[@exteci]

Danke!!!

[@oliverkramer3340]

mega gutes video, wir nutzen wie glaube ich sehr sehr viele, webhooks zur das triggern unserer cicd pipelines

[@Kayamoeu]

KZbin-Recommendations können doch auch positiv überraschend. Super Video :D

[@boka3461]

Bestes video ever, wusste nicht, dass das das ist, was mir fehlt.

[@l4webdesign186]

Ohne dich und ChatGPT hätte ich mein Wirtschaftsinformatik Studium nicht geschafft 😂🚀

[@FilmfanOliver1992]

Bei mir ohne ChatGPT stattdessen mit Stackoverflow und Baeldung

[@chrisderwicht]

Das war mehr zu dem Thema als wir es in der Berufsschule je gelehrt bekommen haben. (FIAE)

[@_cannachris]

Sehr nice erklärt - 7:32 sehe ich da Excalidraw?

[@KevinGeller]

Die Erklärung von Rest ist aber zu rudimentär. Rest kann nicht nur json zurückgeben, sondern kann für jede Art Daten verwendet werden. Dadurch war es früher problemlos möglich, bestehende SOAP-Anbindungen auf Rest umzubauen, ohne dass die komplette Softwarestruktur angepasst werden musste, da die XML auch dann noch korrekt war. Verschiedene Zahlungsdienstleister (darunter auch Paypal) hatten dafür dann einen Rest-Api-Call, der das ursprüngliche XML zurückgegeben hat und wir als Entwickler konnten uns dann in erster Linie um die Verbindung kümmern, bevor man sich an die Verarbeitung gemacht hat

[@robby7292]

Morpheus - The real MVP

[@theGentec]

Huch MQTT als API? Ich hätts jetzt eher als Nachrichtenprotokoll definiert. Aber sind APIs ja auch irgendwie... Wo ist da der Unterschied bzw die Abgrenzung in der Definition? Wie es vermuten lässt nutze ich MQTT recht intensiv. Anwendungsbereich ist die Home-Automation wo ich MQTT als sehr schlankes und leicht skalierbares Protokoll wahrnehme.

[@Noobish1337]

Super informatives Video! Mercure wäre evtl. auch noch interessant gewesen :)

[@HeikoD.]

Allerdings fehlt der Hinweis dass es APIs nicht nur für Webtechnologien gibt. Ohne OpenGL, Vulkan, DX, Metal ... wäre nämlich recht wenig los auf den Endgeräten ;) Um nur Beispiele zu nennen.

[@electronicstv5884]

In der Regel benutze ich für selbst programmierte Websites, Anwendungen etc einfach ne REST API oder MQTT. Aber in vielen Sachen kann man ja auch schon direkt mit der DB zum Beispiel kommunizieren, da braucht man das ganze dann gar nicht mehr.

[@svenreichert6304]

SignalR, wiso hast du das nicht aufgeführt? Ja es verwendet unter der Haube „auch“ Boadmittel der bereits genannten, aber in Abhängigkeit zum Client und Server, wie auch bei gRPC.

[@Rndde]

Gutes Video! Gibt es dieses "API Protocols" Bild zum Download? Das ist eine schöne Übersicht. Grüße

[@andreasmerz2501]

Das fand ich auch super... Hab noch nicht gefunden und im Report ist es auch nicht gewesen...

[@DJone4one]

also damit ich APIs nutze, muss ich erst einmal wisen wie ich sie überhaupt aufbaue und einbaue. Hatte sowas bisher nur im ganz kleinen Grundlagen mit REST-APIs. Wäre vielleicht auch mal gut, ein richtiges gutes Tutorial dazu zu haben.

[@Leonardo_A1]

Great tolle Zudammenfassung👍 Die Bilder bitte einen Tick länger einblenden. Aah und Beispiele wären auch super wie Zb firebase funktioniert mit Api,.. Thanks Leonardo

[@thorsten9211]

MQTT hauptsächlich. Dabke für den Überblick :-)

[@mehdiahmadi2893]

🎉

[@LupinoArts]

Du hättest in den Titel schreiben können, dass es nur um Web-APIs geht...

[@pyuc]

Hi Morpheus, kannst du bitte mal ein Video veröffentlichen in dem du die Berufe als Softwareentwickler und als Webentwickler erklärst bzw. miteinander vergleichst?

[@stn6428]

Jeder Webentwickler ist Softwareentwickler, aber nicht jeder Softwareentwickler ist Webentwickler.

[@pyuc]

@@stn6428 Ich glaube als Softwareentwickler geht man mehr in die Tiefe was Mathematik beispielsweise betrifft. Außerdem arbeitet man länger an Projekten als in der Webentwicklung

[@stn6428]

@@pyuc Naja wie der Name sagt entwickelt man Software. Webanwendungen sind Software. Softwareentwickler ist nur der Überbegriff. Zudem würden meiner Meinung nach auch Software-Architekten etc. dazu zählen, da diese die Software direkt mit planen und entwickeln.

[@codingcrashcourses8533]

@@stn6428 stn6428 hat es vollkommen richtig erklärt. Grüße von einem Software-Engineer, die besser klingende Version eines Entwicklers :p

[@ArneBab]

Bei REST fehlt noch PATCH. Das verwendet unser redux store, um Zustands-Synchronisierung zwischen Backend und Frontend zu optimieren.

[@pedu71]

danke vor allem das du zu deiner alten Form zurück gefunden, und den Kindergarten TicToc Style verlassen hast 🙏,. So sehe ich deine Videos wieder gerne an

[@Timongcraft]

Tja, nutze u.a. Websockets um schnell Daten innerhalb eines Minecraft Netzwerks auszutauschen, hab aber gar nic abgesichert, da die Verbindung intern ist.

[@adrianhillmann3741]

Das SOAP immer unbeliebter wird, rieche ich an ein paar meiner Kollegen. 😂

[@patrick-gundlach]

Hi, gibt es die von dir genuzte Grafik (Übersicht der APIs) ? Cooles Video

[@TheMorpheusTutorials]

In den Quellen sollte die drin sein =)

[@cfo3049]

Super Überblick. Was lohnt sich zu lernen, wenn man in der FinTech-Branche Fuß fassen möchte? Zur Zeit beherrsche ich nur REST.

[@andreasmerz2501]

In FinTech arbeitest du leider eher mit SFTP und CSV Exporten 😢😂

[@cfo3049]

@@andreasmerz2501 ich meine nicht Banken 🏦

[@bilbobeutlin3405]

Würde sagen grpc für alles was Geschwindigkeit braucht (high frequency trading usw) und vielleicht noch websockets. Ich hab in über 6 Jahren als dev eigentlich immer nur mit REST gearbeitet. Und die anderen kannst du dir auch schnell selbst beibringen wenn du sie brauchst.

[@andreasmerz2501]

​@@cfo3049Ich auch nicht 😢 aber leider sind die Kunden meist die Banken und Sparkassen... sei froh wenn es bei dir anders ist 😅

[@onur7183]

Siehe PSD2-Schnittstelle

[@Marfph]

Ich würde mich selbst als Progrmmieranfänger bezeichnen. Und weil es zu dem Video ganz gut dazu passt hier meine Frage die mich schon länger beschäftigt. Wenn ich jetzt eine (neue) Programmiersprache lerne, gehören dazu ja auch so Sachen wie Bibliotheken, APIs usw. Wie geh ich da jetzt am besten vor? Wie lerne ich dass am effektivsten, wo find ich was für Bibliotheken gibt. Gibt's gute Beschreibungen dazu,... Das es viel Zeit braucht ist mir klar, die möchte ich aber möglichst effektiv nutzen. Wie gesagt würde mich selbst als Anfänger beschreiben. Was ich kann ist Siemens SPS programmieren. Das bisschen was ich mit C++ und Phyton Kontakt hatte kann man eigentlich nicht zählen lassen und schon zu lange her.

[@TheMorpheusTutorials]

Das ist ein tolles Thema für ein neues Video 👍

[@andreasmerz2501]

Chat GPT :) bin seit 15 Jahren Dev und diese KI gibt dir zu allem was man sucht eine tolle Antwort, die mindestens als Basis dienen kann. Ich wäre froh gewesen, wenn es dass schon in meinen Anfängen gegeben hätte. Da hätte man sich so einige 'leere' Seite in Sachbüchern sparen können

[@turbo2sven476]

Bei Rest API muss da nicht auch noch HTTPS sein?

[@michaelschuster1554]

Welches Schreibprogramm nutzt du anstelle von MS Office?

[@TheMorpheusTutorials]

Das kommt auf die Anwendung an, meist aber Cryptpad oder Google Docs

[@ytmorris1]

Ich finde es verwirrend, dass die ganze Zeit von API gesprochen wird aber eigentlich die Technologie gemeint ist. Ich verstehe unter API eine Programmierschnittstelle, die von jemandem zur Verfügung gestellt wird und irgendwie eingebunden werden kann. Die Technologie ist da erstmal egal. Das kann auch eine Library sein, die ich statisch einbinde. Es wird auch gesagt, dass die API "der zentrale Platz" ist "um den sich alles dreht". Das ist per se erstmal falsch. Die meiste Software auf einem Rechner ist kein Client in dem Sinne wie hier über APIs gesprochen wird. Nicht alles wird in Client-Server-Architektur mit Frontend und Backend entwickelt.

[@CrazyT2009]

Seitdem postman einem die Cloud-anbindung aufdrängelt, würde ich das aus sicherheitstechnicher Sicht eigentlich nicht so empfehlen. Wer weis was die mit den Passwörtern und API-Beschreibungen so anfangen könnten ... oder halt andere die Zugriff durch einen Hack darauf bekommen? Leider gibts ähnliche Tools, die sich scheinbar für einen ähnlichen Weg entscheiden ... (bisher habe ich allerdings noch keine gute alternative gefunden ... leider gibt es immer irgendwelche Abstriche)

[@silentwater79]

Postman ist für die allermeisten völlig überladen. Würde das nur nutzen wenn man die Features wirklich braucht (z.B. hier Testautomatisierung macht). Wenn Du die meiste Zeit als Entwickler nur einfache Rest Calls machst, schau dir mal Insomnia an.

[@DevMicha]

Hast du dir Insomnia schon angesehen? Oder zählt das bei dir zu den ähnlichen Tools mit ähnlicher Richtung?

[@CrazyT2009]

@@DevMicha Insomia hab ich mir in der Tat schon angeschaut, finde das auch recht praktikabel. Vor allem das mit den Variablen und Ordnern finde ich gut gelöst. Allerdings bin ich mir hier noch unsicher ob das Scratchpad so bleibt oder ob man am Ende doch den Weg von Postman geht. (Scratchpad ist dort ja bereits auf eine einzelne Collection eingegrenzt worden, damit man dazu genötigt wird die Login-Funktion mit Cloud-synchronisation zu verwenden) Httpyac hatte ich mir auch schon angeguckt, das kommt komplett ohne Cloud aus, allerdings ist die Handhabung damit meiner Meinung nach etwas zu abgespeckt. (man schreibt da die Http-Requests pur und kann halt Variablen verwenden) Sonstiges wie "gib mir den request als curl-befehl aus", gibt es dort logischweise nicht.

[@wanderkeule8703]

GraphQL klingt immer erstmal ganz nett, man muss aber Bedenken dass damit auch eine Gewisse Kontrolle über die Verarbeitung an die Queries abgegeben wird. Komplexe Queries können, ohne es direkt zu merken, schnell zu sehr viel Load im System führen indem ggf. unnötig verschiedene Datenquellen vom GraphQL server abgerufen und diese dann auch noch verarbeitet werden müssen. Das heißt, wirklich JEDE Person muss genau verstehen sie tut. Egal ob beim Queries schreiben, oder Resolver implementieren.

[@onur7183]

Das N+1 auf Ebene von GraphQL kann mittels Dataloader gelöst werden.

[@Gromran1981]

In den meisten Fällen ist doch eh die Datenbank der Flaschenhals. Was macht man eigentlich, wenn Entwickler so sehr gesucht werden, aber man nicht der beste Entwickler ist (nach eigener Einschätzung) aber sehr gut interdisziplinär Probleme lösen kann? Meist wird ja Onspot gesucht. Außer vllt in in sehr kleinen Firmen.

[@EnnovonSchwerin]

Hmm, EDI als Schnittstellen-Technologie zu bezeichnen finde ich etwas sehr eigenwillig. EDI ist erstmal nur eine Sammlung von Definitionen das und wie Daten übertragen werden. Ob das nun per Rest-API oder mit irgend einer anderen Technologie passiert ist doch nicht von vornherein festgelegt.

[@FilmfanOliver1992]

Webhooks -> Hollywood-Prinzip, Microsoft Graph nutzt die auch

[@THEMithrandir09]

Das g in gRPC steht für gRPC und nicht google.

[@WickedJackThe1]

Ich entwickle für mein Hands on Seminar an der Hochschule ein remote Firewall-dashboard und denke ich verwende Websockets. Der Client ist in Java und der Servercode ist Python. Ich sage ich denke, weil ich nirgendwo das Wort Websocket gelesen habe. Mein Plan ist eine sichere TCP Verbindung mit TLS im Hintergrund und dazu verwende ich beim Client Java SSE (was anderes als die API SSE, wie ich heute gelernt habe).

Leider sehe ich hier einen großen Fehler, der sehr häufig gemacht. Webhooks ist keine Sprache, sondern eher ein Konzept. Webhooks können sowohl in Soap, XML, Rest usw. Geschrieben werden. Eher seltener in GraphQL,, von der Theo aber möglich. Dieser Fehler wird aber häufig wieder holt.

[@TheMorpheusTutorials]

Hm, das hatte ich aber so nicht gesagt mit der Sprache 😅 Rest ist auch ein Konzept zb

@@TheMorpheusTutorials gesagt nicht. Es kommt aber bei der Vorstellung so rüber. Ansonsten dürfte Webhooks so ja gar nicht genannt werden im Vergleich zu Rest/Soap/GraphQL.

[@rmbl349]

Mqtt,amqp,edi,EDA eh nicht so beliebt?!?!? Mit verlaub, das sind sehr spezielle für bestimmte Anwendungsfälle gedachte Konzepte/Technologien.

[@vulvaa3525]

Sehe ich auch so, ich als absolute Tech Nerd, maxout bla...halt die technische Seite Freak wie Bauer, selbe Zeit, selber drang, PIXEL ! Fühle mich hier jedes mal wohl :) You Dont like me ? You cant say, iam 299tkm run in my bed :) Good night

[@richi1235]

Schade, gerade MQTT hätte mich hier interessiert 😅

[@TheMorpheusTutorials]

kzbin.info/www/bejne/hqCvY5iLeNp2gMk 😏

[@richi1235]

@@TheMorpheusTutorials Na wunderbar, dankesehr! 🙂

[@tobene]

WebRTC kann man auch im Auge behalten 👀 Besonders für P2P anwendungen wie zb. (Video)chat

[@KevinGeller]

Technisch ist webrtc aber keine API, sonder ein offener Standard und somit eine Sammlung von Schnittstellen.

[@onur7183]

So wirklich Peer-2-Peer ist es dann nicht, sondern eher auf theoretischer Ebene. Da kommen dann so Sachen wie Stun/Turn-Server ins Spiel. Btw ist das auch kein "Api-Paradigma"

[@tobene]

@@onur7183 Okay? Dann behalte WebRTC nicht im Auge i guess 😄

[@abdellilahsettah168]

Hä? REST ist auch Single point of failure, was machst du, wenn das Backend nicht da ist? :D

[@JanBebendorf]

Wo ist "RPC over HTTP" aka. 99.99% der API's, die sich REST schimpfen?

[@btx47]

Einmal zwangsweise nen soap request implementiert weil die zugehörige API 30 Jahre alt war. Absolute Katastrophe wer das heute noch verwendet 🐻 gibt sicher andere Möglichkeiten Datenintegrität sicherzustellen

[@silentwater79]

Stimme dem als alter Hase in der Branche zu. Wer heutzutage noch neue Schnittstellen mit SOAP macht, gehört erschlagen. Grüße an die Digitalisierungsbremse Telekom.

[@simonreber3238]

Das war halt in den frühen Nullerjahren absolut der Standard für APIs. Vorher gab es jede Menge proprietäre Lösungen, welche meist noch sehr viel beschissener zu verwenden waren. Für SOAP gibt es immerhin einige Tools, welche die ganze Sisyphusarbeit erheblich erleichtern und den ganzen komplizierten Code generieren können. Muss man halt kennen und nutzen.

[@michaelbauer8778]

Mqtt ist macht

[@nitro424]

Postman mag ich nicht mehr seit dem sie das Offline Scratch Pad entfernt haben.

[@WickedJackThe1]

Bitte benutzt nicht Discord, wenn euch die Sicherheit eurer Daten irgendetwas bedeutet.

[@silentwater79]

Wer heute noch für neue Schnittstellen SOAP benutzt, gehört ausgepeitscht und gevierteilt. SOAP stirbt hoffentlich bald aus (auch wenn man bei Legacy Systemen und langsamen Großkonzernen häufig noch darauf trifft (grüße gehen raus an die Telekom (die Digitalisierungsbremsen)). Dagegen hätte ich hier MQTT mit aufgenommen, was vor allem im IoT Bereich oft Anwendung findet.

[@simonreber3238]

Das wird noch lange überleben. Durch die sehr formale Beschreibung sind auch sehr viele Automatisierungen möglich, welche zb mit simplem REST nicht möglich sind. Und wenn man konsequent mit WADL arbeitet, dann ist der Aufwand auch nicht viel geringer. Viele Software-Dinos, wie SAP, bieten halt eine teilautomatisierte SOAP Schnittstelle. Und bis die sich ändern, dauert es halt ...

[@Olim22]

Finde ich überhaupt nicht. Es kommt immer auf den Anwendungsfall an. Für SOAP gibt es genauso use cases wie für z.B. plain REST, ODATA, Eventing und sogar einfaches SFTP file Geschubse. Es gibt wesentlich mehr Anwendungsfälle im echten Leben als reine Frontend Integration.

[@elmariachi5133]

Web ist Kotze.