Vielen Dank für die Klarstellung und das tolle Video.
@Sterdinho
11 ай бұрын
Sehr interessant, danke :) Wir führen gerade API First ein und ich bin skeptisch. Aber mir fehlen noch die Erfahrungswerte. Mir erschließt es sich auch nicht ganz, wieso die fachlichen Anforderung so früh schon in, meist REST, API gegossen werden sollen.
@dape9912
11 ай бұрын
Kannst du einmal API Design First erklären? Wo ist der Unterschied zu API First?
@thomas-bayer
11 ай бұрын
API Design First heißt, dass du erst die API Beschreibung erstellst und dann daraus z.B. durch Generierung die Implementierung und den Client ableitest. Du kannst dabei iterativ und agil vorgehen, in dem du z.B. schrittweise die Schittstelle vergrößerst oder erst Beta-Versionen auslieferst, bevor du die Version 1 verabschiedest. API First hat als Bestandteil auch API Design First, geht aber darüber hinaus. Eine Beschreibung zu API First findest du im letzten Video kzitem.info/news/bejne/uaSjmJydcaBniIo
@michster32
11 ай бұрын
"Gutes" Beispiel ist Shopware. Mit Version 6 wurde eine komplett neue API im API First Ansatz umgesetzt. Ich als Entwickler, der die Shopware 6 Admin API anbinden soll, bin etwas überfordert. Weit über 100 Endpunkte und die Dokumentation ist stark ausbaufähig. Für meinen Teil sehe ich hier keinen Vorteil, warum diese API so umgesetzt wurde. Und trotzdem fehlen mMn grundlegende Felder und Funktionalitäten eines Shopsystems. Hat hier noch jemand Erfahrung mit der SW6-API gemacht oder bin ich der einzige mit diesem Problem?
@raphaelflash
4 ай бұрын
Die Shopware Admin API wurde so umgesetzt, weil die Shopware Administration eine decoupled SPA ist. Das heißt jede Aktion, die in der Administration durchgeführt werden kann, verwendet im Hintergrund die Admin API. Der große Vorteil für uns ist, dass auch für Erweiterungen und Drittsysteme jede Entität per API kontrollierbar ist.
@Pantosilas
11 ай бұрын
Weshalb veröffentlicht man bei „API First“ die API Spec schon so früh und kauft sich dadurch so viele Nachteile ein? Ich schätze man will Zeit gewinnen und anderen Teams schon früh ermöglichen, gegen die bereits definierte Schnittstelle zu entwickeln. Am Ende führt dieser scheinbare Vorteil aber nur zu Mehraufwand für alle.
@predic8
11 ай бұрын
Gute Frage. Der "API First" Ansatz wird hauptsächlich von den Herstellern von API Werkzeugen in Blogposts, Artikeln, Vorträgen, ... "gepushed". Die Hersteller haben Tools, mit denen man zusammen an einer OpenAPI Spec arbeiten kann. Dort gibt es auch die Mock-Funktionalität zum Simulieren. Das sind nützliche Werkzeuge, ich bezweifle aber, dass Zusammenarbeit und Simulation das Feedback aus der Produktion ersetzen können.
@chrisre2751
11 ай бұрын
Interessantes Video. Also wenn ich von API-First spreche, dann würde ich aber ein andere Definition nennen als Du. Wieso sollte man bei der API-Spezifikation nicht auch agil vorgehen? Und ich rede hier von bis zur Implementierung. Wieso muss die API-Spezifikation zuerst gepublished werden? Ich würde das alles iterativ machen und es trotzdem einen API-First Ansatz nennen. Aber wie gesagt, ich vermute einfach, dass wir für das Wort unterschiedliche Definitionen haben.
@thomas-bayer
11 ай бұрын
Der Begriff „Contract First“ oder „API Design First“ steht dafür, mit der API-Beschreibung zu beginnen. Man kann so vorgehen wie du es beschrieben hast. Meine Kritik gilt „API First“. Das ist ein Vorgehen, das von API-Playern geprägt ist und bei dem die API vor der Implementierung finalisiert wird. Anstatt Feedback aus der Produktion wird Feedback bei API First mit Hilfe einer Simulation(Mock) erzeugt.
@yasinicdeniz9617
11 ай бұрын
Und welches Ansatz ist jetzt der richtige? API Design First?
@thomas-bayer
11 ай бұрын
Was das Richtige ist, hängt von den Anforderungen und Randbedingungen ab. Unter bestimmten Umständen könnte auch "API First" das Richtige sein. Bei API First ist jedoch die Gefahr groß, dass man nicht agil vorgeht. Mit dem Video möchte ich darauf aufmerksam machen, dass API First nach Lehrbuch dem Wasserfallmodell gleichkommt. Wenn man sich dessen bewußt ist, kann man das in seine Entscheidung einbeziehen. Auf der Suche nach dem passenden Ansatz sollte man sich die Fragen stellen: Wer benutzt die API? Wird es unbekannte Benutzer außerhalb der Organisation geben? Wieviele Nutzer wird es geben? Wer hat die Kontrolle über die Clients? Wie genau kenne ich die Domain? Wie möchte ich mit Änderungen umgehen? Wie lange muss ich alte Versionen unterstützen? ...
@yasinicdeniz9617
11 ай бұрын
@@thomas-bayer Vielen Dank fuer die Antwort ... Das hoert sich gut an, bin ein Freund vom Wasserfallmodell :) Waere aber fuer mich jedenfalls interessant wenn du ein Video auch zu API Design First erstellen wuerdest. btw kommst sehr sympatisch rueber und fachlich up to date :) Kein Klugscheisser sondern ein Spezialist der aus Erfahrungen berichtet. Vielen Dank fuer deine Zeit.
@predic8
11 ай бұрын
Danke für das gute Feedback. Tatsächlich möchte ich bald ein Video zu API Design First und dem Generieren von Code aus OpenAPI machen.
@emergenz774
11 ай бұрын
Ein Wasserfallmodell wurde noch nie real verwendet und erfolgreich umgesetzt. (evtl. ein "Hello World")
@FilmfanOliver1992
11 ай бұрын
Die Bundeswehr hatte früher Wasserfallmodelle in ihrer IT verwendet
@yasinicdeniz9617
11 ай бұрын
Heute noch immer bei BWI und anderen privatisierten Tochterunternehmen
@emergenz774
11 ай бұрын
@@FilmfanOliver1992 Na das erklärt, warum am Ende nichts funktioniert, denn wenn nur ein Mitarbeiter oder eine Kleinigkeit abweicht vom Plan ist es gescheitert !
@emergenz774
11 ай бұрын
@@yasinicdeniz9617 Ich denke nicht, dass das wirklich der Fall ist, denn jeder Wasserfallmodell scheitert in der Realität an nicht planbaren Ereignissen. Das ist ein rein Akademisches Modell ohne reale Chance
Пікірлер: 20