Warten wir mal, ob die Tür zufällt. Alles klar, dann würde ich mal anfangen. Ich mache mal gerade die Maus auf Seite.

Genau, was ist das Ziel, was ich versuchen will, mit dem Vortrag ein bisschen beizubringen? Das Ziel ist, dass wir Anwendungen relativ schnell, also Rest-APIs relativ schnell erstellen können. Das heißt, wir brauchen jetzt nicht irgendwie riesige Sachen importieren, stundenlang coden, bis da irgendwie so ein Rest-API rausfällt. Sie soll möglichst einfach zu testen sein. Das heißt, dass wir einfach schnell darauf zugrafen können.

Damit wir sehen können, was wir machen und nicht irgendwie durch den JBoss-Server das auch immer kompilieren lassen müssen, fünf Tage warten bis dann die Ops gesagt haben, hey, kannst du machen, dann läuft das. Dass wir das möglichst mit einem Klick deployen können, also zum Beispiel auf den Server schieben können, oder eben noch viel besser, sogar automatisiert das Ganze deployen können. Dass wir am Ende des Tages genau eine Zeile Code brauchen, also eine Zeile Shell-Code,

die wir ausführen können, wo das ganze Ding hochfährt von alleine, sich konfiguriert und einfach läuft. Und natürlich auch von außen konfiguriert werden kann. Also nicht nur einfach irgendwie hochfahren, denn wir brauchen hier für verschiedene Umgebungen, die wir haben, brauchen wir verschiedene Variablen. Das fängt schon mit einem Server-Namen zum Beispiel an oder mit einem Ports, unter dem so eine Anwendung erreichbar ist. Darüber hinaus wollen wir Dokumentation möglichst einfach erstellen,

und zwar ohne, dass wir zum Beispiel ein Office-Dokument erzeugen müssen und da irgendwie händisch reintippen müssen. Denn die meisten von uns wissen, nichts ist so schnell veraltet wie Dokumentation, die ich gestern geschrieben habe. Denn ich habe den Code heute schon wieder verändert und wenn ich die Doku schon wieder halte, müsste ich sie anpassen. Also ist das Ziel eigentlich, die Dokumentation am Code zu haben, auch wenn es den Code vielleicht ein bisschen unnötiger macht,

weil eben Dokumentare am Code noch dran stehen. Aber eben wenn ich die Klasse ganz wegschmeiße, verschwindet auch automatisch die Dokumentation dazu. Ich brauche mir also nicht irgendwie die Mühe zu machen, noch was neu zu schreiben, ständig das Dokument anzupassen, immer nachzuhalten. Und das Bonus-Feature on top, ich bin auch in der Lage, mit den eingesetzten Tools eine SDK einfach so zu erzeugen.

Ich muss die Programmiersprache nicht verstehen, die das SDK erzeugt. Ich brauche nichts zu machen, außer das, was da rausfällt, zu nehmen, also die Maschinenlesbare Schnittstelle zu nehmen und einfach zu sagen, dafür brauche ich jetzt eine SDK. Das heißt, da kann jeder Entwickler einfach das Ding anbinden, nutzen und kann sie vor allem jedes Mal, wenn ich irgendwas verändere, kann ich sie einfach neu bauen lassen.

Der grobe Fahrplan für heute sieht so aus, ich werde gleich kurz etwas über mich erzählen, über die Firma, für die ich arbeite. Dann werden wir auf Jobreset eingehen, das ist das Framework, was dafür da ist, die Rest-APIs zu bauen, in Java in diesem Fall. Und danach gehe ich auf Swagger und Swagger UI ein, das ist so ein bisschen so eine Einheit, die dafür sorgt, dass das eben die Rest-API-Maschinenlesbare dokumentiert ist.

Und auch für User, UI vor allen Dingen, eine UI aufbereitet wird, wo man klicken kann, testen kann. Fangen wir kurz an, ich bin Bernd Schönbach, burnt, wie es im Programm steht. Ich habe mit PHP-Entwicklung angefangen, ganz am Anfang von meiner Uni-Karriere quasi, 2001.

Und habe dann im Studium angefangen mit Java-Entwicklung und arbeite seit, jetzt sind es fast drei Jahre, bei der Firma Linux und mache da Java-Entwicklung. Hauptsächlich Backend-Entwicklung, wir bauen eben Market-Services mit Rest-APIs, mit anderem und dran. Das heißt im Prinzip, mit PHP-Maschinenlesbare angefangen, so der klassische Start,

man fängt an mal ein bisschen zu rumzuhacken, zu coden, Webseiten zu machen. Geht das Ganze auf die Ebene Typo 3, also ein Content-Management-System, dafür Extensions schreiben, immer noch quasi das Wissen weiter vertiefen. Und jetzt geht es halt weiter mit Java und Postgres-Datenbanken und in einem etwas fänzigeren Stack, in diesem Fall mit Docker-Umgebungen.

Das ist das Job-Resort-Hütchen, werden wir heute noch ein paar Mal sehen, und mit Swagger, also Market-Services, die mit Docker geschickt werden, Java mit Java gebaut werden und mit Swagger-Dokumentationen zur Verfügung stellen. Was ist das Tool, die Firma für dich arbeite? Wir verkaufen ein Tool, ich versuche das so kurz wie möglich zu halten, ihr wollt ja Inhalt haben und nicht den Firmen-Content. Das ist ein verkaufendes Tool, um große Unternehmen, nicht IT-Unternehmen, einen Überblick über ihre IT-Infrastruktur zu verschaffen.

Und zwar nicht auf einem Niveau von wegen, welche Lizenzen hast du, sondern auf dem Niveau, du hast Office zum Einsatz, wie lange wird das maintain from, oder welche Abteilung setzen das alle ein, auf diesem Niveau, also ein relativ hohes Niveau.

Und die Key-Features sind hier so, dass man halt relativ schnell die Sachen umsetzen kann, wir können mit Metriken so eine relativ schnelle Einsicht geben in Probleme, die du im Microsoft oder in deiner ganz neuen Umgebung hast, es ist schön einfach zu skalieren, weil es eine Web-Oberfläche ist, das heißt Software as a Service oder bei dir auf dem Server-SD, du kannst es easy skalieren, einfach zu nutzen, dadurch, dass es im Browser läuft,

kann es jeder Nutzer, der im Unternehmen einen Browser hat, benutzen. Und du kannst es halt alles integrieren, du kannst es automatisch ansteuern über die Rest-Apps, die wir so nutzen, das ganze so. Ja, das ist die komfortabelste Software-as-a-Service-Lösung im Enterprise Architecture-Mainframe-System. Ich klicke mal kurz weiter.

Diverse Kunden, die wir nutzen. Und das ist eigentlich, glaube ich, der spannendere Part, unser Stack, den wir gerade benutzen. Wir haben im Frontend eine Angular-2-App, die quasi das Frontend-UI bildet, könnte fast sagen der Frontend-Modulit. Eine Single-Face-App quasi, die da steht. Und dahinter stehen verschiedene Markerservices. Das heißt, wir haben Markerservices, die sich zum Beispiel ums Login

kümmern, um Export von Daten kümmern, um Bildererzeugung und Darstellung kümmern, Survey für Umfragen da sind oder auch Metriken erfassen können. Und an denen hängen quasi verschiedene Technologien. Das heißt, zum Beispiel unser Hauptmodul, das ist quasi unser Haupt-Service, das ist nicht mehr ganz ein Markerservice, das ist ein Haupt-Service, der nutzt an verschiedenen Technologien, zum Beispiel Postgres-Datenmanken zum Speichern, Elasticsearch für schnelle Suche, ähnliches.

Oder hat noch verschiedene andere Ansätze. Das ist grob Linux. Kommen wir zum Content. Job Wizard. Job Wizard ist im Prinzip ein Java-Framework für Restful-Web-Services. Das ist das, was quasi das ist. Also man kann Rest-Services mit Job Wizard bauen.

Es erlaubt einem möglichst einfach, das aufzusetzen. Man braucht im Prinzip nur die Dependency importieren mit Maven, setzt den Service kurz auf und dann läuft das alles. Das zeige ich auch gleich. Wir machen gleich ein paar Live-Calling-Beispiel. Wir machen das hier nicht nur am Text, sondern ich zeige euch gleich, wie man so einen Markerservice aufsetzt. Das Ganze kannst du komplett konfigurieren, wie du möchtest. Du kannst die Ports konfigurieren, die das Ganze nutzt, die Adressen konfigurieren und auch sonstige Dinge konfigurieren.

Und zwar so, dass du das zum Beispiel auch über eine Environment-Variable injecten kannst. Das heißt, wenn du sagst, du hast den Service-Supply auf Server A oder Server B und da gibt es verschiedene Umgebungen, die benutzt werden müssen. Verschiedene Adressen, die gelten. Dann kannst du das über eine Environment-Variable einfach über die Konfig reinsetzen, ohne dass ich den Service irgendwie anpassen muss händisch.

Sondern das kann ich dann von außen steuern und kann die Daten übernehmen. Aktuelle Version ist Version 1.1.2. Wir werden da etwas jünger und nicht ganz die aktuellste Version nutzen, weil ich das etwas anders installiere. Zu Präsentationszwecken. Das ist ein bisschen einfacher.

Weiter, was ist in diesem Framework überhaupt eigentlich alles drin? Wir haben quasi einen Jetty, der als HTTP-Server dient. Da drauf läuft ein Jersey, der dafür sorgt, dass diese Rechtsschnitte herangebunden werden. Das ist quasi eigentlich keine Rocket-Size. Das sind alles bekannte Pakete, die sind einfach schön gebundelt. In der richtigen Version liegen die vor, sodass du es nicht selber irgendwie konfigurieren musst und wissen musst, welche Version von Jetty arbeitet und welche Version von Jersey.

Das ist alles zusammen. Jackson wird genutzt, um Jason-Transformation zu machen. Das heißt, du schmeißt Jason-Objekte rein und das Jackson sorgt dafür, dass das in die Java-Models gemapt wird, die du intern nutzt. Und genau den Weg auch zurück. Sodass du intern nicht mit Jason-Strukturen arbeiten musst, nicht mit Textfiles oder was auch immer. Du kannst mit deinen alten Pojos arbeiten, also mit deinen klassischen Java-Objekten, die du so hast.

Und Jackson sorgt dafür, dass die Transformation von außen nach innen passiert. Das heißt, unsere restliche Stelle quasi bekommt Jason-Daten und liefert Jason-Daten auch wieder aus. Das ist so das Grundprinzip. Und Hibernate natürlich, um Datenmarken zuzugreifen. Das ist Standard-Tool, würde ich sagen. Dann gibt es noch ein paar weitere nützliche Sachen.

Das eine ist das Metrix-Modul. Damit kann man Metriken erzeugen. Also zum Beispiel Statistiken, wie viel Zugriff habe ich pro Sekunde. Ist mein Server healthy? Da kann ich zum Beispiel auch so Sachen testen, wie ist die Datenmarkenmehnung da und reagiert die auch schnell genug. Da kann man relativ einfache Health-Checks damit implementieren. Und das ist ein super Tool, um herauszufinden, ist mein Service überlastet oder nicht.

Wenn man die Metriken vorher gesetzt hat, vernünftig konfiguriert hat, kann man halt wirklich schnell herausfinden, auch wie da über ein Dashboard oder ähnliches läuft der ganze Kram. Liquibase, ein Tool zur Migration von Datenmarkedaten. Also zum Erzeugen von Tabellen, Feldern, umbenannten Constraints, was man so alles braucht. Und halt noch so Logging, was auch immer im Entwicklungsprozess immer ziemlich wichtig ist.

SLF4j und Logback. Wie weit runter sieht man das eigentlich von unten? Wie weit siehst du? Da? Alles klar, das ist Liquibase. Wir gucken mal. Vielleicht könnt ihr gleich noch mit Copa spielen, aber da kriegen wir das irgendwie hin. Darunter gibt es natürlich noch tausend weitere Erweiterungen und Sachen, die da eingebunden sind,

die man halt, wenn man sie braucht, irgendwie bei Bedarf nutzen kann. Was sind also die ersten Schritte, die man eigentlich machen muss, um Drop-Reset zu installieren? Wir erzeugen einfach ein ganz normales Maven-Projekt. Also ein Java-Projekt, das Maven nutzt. Wir fügen quasi die dependency zu Drop-Reset hinzu. Und konfigurieren das Maven-Shade-Plugin. Das Maven-Shade-Plugin sorgt dafür, dass wir nachher, wenn wir das Ganze gebaut haben,

nach dem Package einen FAT-JAR haben, wo alle Klassen und Dependencies drin sind. Das heißt, dass ich einfach starten kann mit Java-JAR. Den JAR-File hinten dran, dann läuft das Ganze. Das heißt, dann ist es viel einfacher zu shipen. Ich muss am Ende des Tages nur die JAR-File auf den Server legen. JAR muss ja darauf da sein, dann kann ich das laufen lassen. Es kommt noch eine weitere Anhängigkeit dazu. Da kommen wir über gleich noch dazu.

Nämlich die Konfigurationsdatei. Das heißt, man kann optional natürlich konfigurieren. Das ist zwar alles out of the box so halb fix-sane definiert, aber du willst halt für gewöhnlichen Ports haben, wo die Anwendung normal drauf lauscht. Zum Beispiel Port 80 und nicht Port 8080. Und du willst, dein Server heißt wahrscheinlich auch nicht localhost, sondern hat irgendeine Ahnung, heißt wahrscheinlich irgendwie anders. Genau. Und dann kannst du im Prinzip loslegen. Dann kannst du deinen Code schreiben, der die Logik dahinter sitzt.

Und dann läuft das Ganze. Jetzt mal ein ganz einfaches Beispiel. Wir fügen hier quasi so eine POM-Dependency hinzu für ein Maven-Projekt. Wenn irgendjemand nicht mitkommt, gerne Fragen stellen zwischendrin. Das ist aber, wie gesagt, Judau und Maven-Kram sollten die meisten hoffentlich kennen. Ich hoffe das zumindest. Das heißt, wir sagen nur, welche Version von Drop Wizard nutzen wir.

Und fügen quasi als Dependency einfach den IO-Drop Wizard-Core hinzu. Und sagen halt, die Version soll benutzt werden. Das ist im Prinzip schon alles. Dann machen wir einen Maven-Clean-Package zum Beispiel. Dann hast du das heruntergeladen. Und dann läuft das. Wir, wie gesagt, nutzen etwas andere Versionen. Wir nutzen nämlich ein Plugin, was Drop Wizard und Speckart zusammen benutzt. Also was, wo beide Dependencies automatisch mit reingezogen werden.

Das hat den Vorteil, dass es ein bisschen einfacher ist, herauszufinden, welche Version von Drop Wizard mit welcher Version von Speckart zusammenarbeitet. Da die beiden ganz gut entwickelt werden, kann das mal passieren, dass eine Version von Drop Wizard nicht so gut mit einer Version von Speckart funktioniert, die gerade da ist. Da kann man so ein bisschen in die Dependency-Hölle irgendwann landen. Und ich habe mir für die Demo-Zwecke entschieden, habe ich mich entschieden, quasi so ein Kombipaket zu nehmen,

wo einfach die Versionen richtig passen. Dann brauchen wir uns jetzt hier nicht gleich herumzuschlagen, welche Version gerade wie irgendwo passt, sondern in ein Paket rein fertig, glaube ich. Wenn man das selber, wie gesagt, kann man das immer noch machen. Das kann man aber manchmal zu komischen Problemen führen, wenn man selber das versucht zu konfigurieren, die richtigen Versionen herauszufinden. Vor allen Dingen, weil bei Drop Wizard sehr, sehr viele Pakete, wie wir heute gesehen haben, hinten dranhängen.

Also viel Jersey-Jetting, den ganzen Kram. Da kann es mal zu Konflikten führen. Dann müssen wir noch den Made in Shape-Laggen konfigurieren. Das heißt, wir sagen, wir brauchen hier so eine Dependency, wir bauen hier quasi unseren Output-Fall zusammen. Das würde in diesem Fall Force-Contest-Jar heißen, wo einfach alles reingeworfen wird. Dann lasst uns das nochmal angucken.

Vermutlich seht ihr mich jetzt nicht mehr, aber ihr hört mich auch nicht noch. So, dann gehen wir mal rein. IntelliJ sollten die meisten von euch kennen. Wenn es zu kleines Bescheid ist, soll ich größer machen? Ich frage mal nach da hinten. Oder liest du gar nicht mit? Ach, sehr gut. Warte mal kurz.

Das kannst du lesen. Das ist ja super. Dann machen wir mal die Präsentation aus. Das ist ja auch fancy, du hast jetzt einen zweiten Monitor aufgemacht. Das ist ja super.

Dann machen wir mal die Präsentation aus. Das ist ja witzig. Wo bist denn du? Ah, das ist ja sehr faszinierend. Wieso ist denn das jetzt so? Warte mal. Ah, ist kein Problem, dann drehe ich mich einfach um zu coden. Das kriegen wir hin.

Warte mal, ich zoome mal ein bisschen rein. Kann man das lesen? Halbwegs. Wo kann ich das Licht ausmachen? Da irgendwo rechts. Wir gehen mal Licht ausmachen. Ich drücke mal, sonst geht hier gleich die Technik aus.

Sonst kriege ich wahrscheinlich gleich haue. Nee, der hier? Nee, das macht noch mehr Licht an. Warte mal kurz. Jetzt kriege ich gleich Ärger wahrscheinlich.

So. Man kann es ein bisschen besser lesen. Ich zoome einfach noch ein bisschen weiter rein. Dann sieht man noch ein bisschen mehr. Hab ich auch gerade drüber nachgedacht. Das können wir fix ändern. Das ist ja kein Problem. Tauchen die bei euch die Preferences? Oder bei mir?

Appearance. Dann machen wir einfach ein Default. Ich glaube, das Default ist aber auch ein dunkles. Nee, guck mal. Jetzt kann man das auch lesen, was hier steht. Was wir hier schon sehen. Wir haben hier unsere Struktur. Wir haben einen Package. Der Ding ist Froscon. Und in diesem Package liegt die Hauptklasse des Programms. Das ist die Appklasse.

Die wird quasi ausgeführt, wenn wir das Java starten. Das heißt, hier läuft, also hier wird die Main-Bethode aufgerufen, wie das halt so ist. Und dann wird halt hier ein Run aufgerufen. Und dann läuft die Anwendung, wenn ich im Server-Modus starte, und läuft einfach vor sich hin. Solange bis ich sie quasi terminiere. Was wir jetzt auch sehen. Ich hab schon mal einen Model angelegt.

Damit wir auch irgendwelche Daten durch die Gegend schicken können. Das ist einfach eine Person, denn die hat eine E-Mail, einen Namen und eine ID. Da wird noch nicht viel von benutzt. Die ist einfach nur da. Und das erste, was wir jetzt also erzeugen müssen, wäre meine Restresource. Das heißt wir brauchen irgendwas, wo wir uns hinspringen können. Genau, jetzt haben wir einen Tisch weg. Das heißt, das erste, was ich erzeuge, ist tatsächlich eine Person-Resource.

Das ist auch nicht so kompliziert. Wenn ich im richtigen Projekt bin, dann klappt das auch. Das heißt, wir machen einfach hier ein neues Package auf. Ah, so langweilig ist es schon. Wir machen dann das Ding Resource. Das ist einfach halt halber.

Und erstellen jetzt hier eine neue Java-Klasse. Die nennen wir Person-Resource. Und nicht vertippt. Sehr schön. So, was braucht die Klasse? Die hat eigentlich nicht so viele Bedingungen. Das eine, was wir hier halt sagen müssen, ist, dass sie einen Pfad hat. Das heißt, das ist die erste Annotation, die wir an die Klasse dran schreiben.

Das heißt, Job Wizard arbeitet viel mehr Annotation. Das heißt, ich schreibe jetzt hier Pfad hin. Kriege ich auch gleich schon vorgeschlagen. Da, das ist Jax. Das ist wie wir sehen. Und die sagt halt, der Pfad, der hinten soll Persons heißen. Also die erste Entscheidung, die ich treffe, die Ressources unter Persons zu erreichen. Ja, kann ich machen.

So, passt so? Alles klar. Genau, und jetzt brauchen wir natürlich noch eine Funktion, die das Ganze irgendwie ausbaut. Das heißt, machen wir Person-Funktion, die eine Person zurückliefert. In unserem Fall einfach mal, erzeugen wir jedes Mal ein neues Objekt. Das ist zwar nicht so schön, aber für Demo-Zwecke natürlich vollkommen geeignet.

Das heißt, die erzeugende Person, die heißt Max, und max-at-test.com. Und dann fehlt uns noch eine ID, die nehmen wir 1, 2, 3. So. Jetzt machen wir noch das R weg bei Return, und dann läuft das.

Ah, das R an der falschen Stelle, sehr gut. Genau. Das heißt, jetzt haben wir an dieser Stelle einfach eine neue Person erzeugt. Wir haben Ruhe. Die jedes Mal, wenn ich Geld zurückreiche. Okay, jetzt weiß aber Dropweiser noch gar nicht, ob die Funktion überhaupt relevant für mich ist. Also weiß Dropweiser, ist das eine Funktion, die ich aufrufen soll. Also sage ich, das ist eine Geldressource.

Dann habe ich quasi eine Ressource gebaut, die jetzt eine Person zurückliefert. Es gibt noch eine wichtige Besonderheit, die man hier angeben muss. Nämlich, man muss sagen, was frisst diese Anwendung, und was liefert sie zurück. Dafür gibt es Produces und Consumes-Annotationen. Und wir nehmen hier Via-Type.

Da wollen wir hin. Ja.

Ja, you can also use an interface, if you want to. So you can provide an interface, where the producer consumes annotations are marked, and this will also be inherited into these classes.

Yeah. So, it's just for demo purposes. I'll do it directly into this class. So that we have a small program. Just to show that it's a small program. Genau, und das ist es eigentlich schon. Jetzt haben wir eine Ressource definiert. Und haben gesagt, da gibt es einen Get-End-Funk, der eine Person zurückliefert.

Wenn ich das jetzt versuchen würde zu machen, das war der Tisch, dann würde das so nicht funktionieren, denn eigentlich weiß unser Anwender noch gar nicht, was er überhaupt gibt. Das heißt, der Server hat noch nicht begriffen, dass da überhaupt Ressourcen-Klassen da sind. Jetzt ist das Ton wieder da. Ich nehme das mal aus der Tasche, wenn ich mich hinsetze.

Wenn ich mich nicht kaputt mache. Das heißt, ich muss ihm jetzt noch sagen, dass in unserem Environment, der Jersey-Server, noch eine Ressource braucht. Also registriere ich die einfach beim Server. Man kann das auch in einem Juice-Bundle automatisieren. Also man kann einfach sagen, hey, hier gibt es irgendwie einen Package.

Da liegen alle meine Ressourcen drin. Und dann macht er eine Auto-Discovery. Das heißt, mit diesem Juice-Auto-Bundler brauche ich da nicht jede Ressource einzeln angeben. Das können ja auch mal viele werden. Sondern dann sage ich einfach, hey, hier, das Package heißt Ressource. Da guckst du einfach nach einer Ressource drin. Und dann findet er das auch alles von alleine. Das war's schon. Das heißt, jetzt kann man versuchen, den Code laufen zu lassen.

Jetzt machen wir mal einen Terminal auf. Den da zum Beispiel. Jetzt gucken wir mal, wo der runterkommt. Da kommt er. Der ist auch noch so gar nicht zu lesen. Da haben wir noch einen X-Term oder so was drauf. Na, bleibt mal hier.

Da haben wir noch so ein normales Terminal. Da kann man doch bestimmt auch den Farbkod umstellen. Guck, da kann man das noch lesen. Wenn wir das noch ein bisschen größer machen, könnt ihr das da hinten auch lesen. So, jetzt gehen wir uns richtig repo rein.

Da sind wir schon ein bisschen zu weit vorne. So, hier liegt unsere ganze Java-Anwendung drin. Was wir jetzt ein Prinzip machen müssen, ist ein Make-and-Clean-Package. Also, dass die Java bauen. Clean kann man sich jedenfalls auch sparen, aber ich mach's mir immer gerne clean. Jetzt wird das Ganze lustig gebaut.

Fertig. Und zum Starten starten wir einfach Java-Jar. Sagen an, wie heißt unsere, also, fatjar. Und sagen, wir wollen einen Server starten. Das Hinteres des Commandos, dass das DropWiz-Advice, hey, ich versuche jetzt einen Server aufzufahren und nicht irgendwelche anderen Commandos zu machen.

Das wäre zum Beispiel BBMigrate. Man kann aber auch selber noch Commandos erzeugen. Also, man kann auch sagen, ich hab irgendwie zum Beispiel bestimmte Migrationen, die immer stattfinden müssen, oder bestimmte Vorarbeiten, die kann ich dann über ein eigenes Kommando steuern. Und was passiert jetzt? Das Ding fällt hoch. Und wir sehen jetzt hier auch schon, der hat jetzt drei Endpunkte erzeugt.

Er hat einmal einen Get-Endpunkt erzeugt, Persons, das ist der, den wir definiert haben. Dann hat er noch so ein Task und ein Task-Garbage-Collector-Post-Endpunkte erzeugt. Wir haben das bisher noch nie gebraucht, weil eigentlich ist das Java fit genug, um das selber auf die Reihe zu kriegen. Vielleicht gibt es Gründe, warum man das haben möchte. Aber die Tasks existieren, die kann man benutzen.

Wie gesagt, Log-Configuration brauchst du eigentlich auch nicht, wobei du es halt nutzen kannst, um das Log-Level on the fly zu ändern. So, jetzt die spannende Frage. Kommt dann auch was zurück. Jetzt hab ich ja gesagt, er hat ja nichts konfiguriert, das heißt eigentlich muss ich jetzt einfach gucken, wo ist denn der Server? Und dafür gehen wir jetzt einfach mal

in den local. Gucken wir einfach mal, wo das ist. Der ist nämlich unter dem Standard-Port 8080 verfügbar. 8080. Und die Ressource, das hab ich vorhin definiert, ist Persons. So, was kommt zurück? Es kommt quasi in JSON zurück. Das ist genau das, was wir definiert haben. Wir haben eine Person-Klasse erzeugt, die wird zurückgeliefert und das war's. Das heißt, wir haben jetzt quasi gerade

einen Rest-Appi geschrieben. Der ist jetzt sofort ansprechbar. Klar, lokal. Ich hab nicht gesagt, nimm Dutzend anderen Port oder erwarte eine Autorisierung oder ähnliches. Aber so funktioniert's. Dann gehen wir zurück zum Vortrag.

Und gucken so ein bisschen, was gibt's denn noch? Ich hab ja gesagt, die Anwendung kann man konfigurieren. Das heißt, was man sinnvollerweise konfigurieren möchte, ist der Server. Das ist logisch. Das heißt, man sagt, man kann die Anwendung nicht nur durch Quests lesen oder HTTP. Und unter welche Port ist der ganze Spaß erreichbar?

Die zweite Stelle, die wir noch haben, sind die Admin-Connectors. Das heißt, es gibt noch so, diese Tasten, die wir gesehen haben, die sind zum Beispiel unter Admin zu erreichen und auch zu Sachen wie den Health-Check oder ähnliches. Dafür gibt's extra eine Admin-Section unter einem anderen Port, damit die User nicht darauf zugreifen können. Es ist ein bisschen so Security by Obscurity, den Admin-Port zu verstecken, weil man im Endeffekt ganz hinraten.

Wenn dir eine variable Variable Admin-Port gesetzt ist, dann nimm die. Der Doppelpunkt sagt, wenn es in dir nix findet, dann nimmst du einfach die 1338. Das heißt, das ist auch schon die Konfiguration hier. Das wird injektiv vom Server. Das kann ich irgendwann in die Variable vom Server reinschmeißen.

Dann hab ich einen neuen Port, wie ich das haben will. Man kann auch noch so Log-Levels definieren. Die kann man auf Package-Ebene sogar, nee, sogar auf Klasse-Ebene feindlich konfigurieren. Ich kann nur sagen, diese Klasse soll mehr und andere weniger rauslaufen und loggen. Und man kann natürlich auch selber values definieren. Das zeige ich auch gleich noch kurz.

Das haben wir gesehen. Ich habe eine Person-Endpunkt gebaut. Den Pfad habe ich definiert. Das geht natürlich auch mit PostPort-Delete. Ist ja klar. Ich meine, wir wollen den Rest abgebauten. Dann müssen alle Methoden unterstützt werden. Die URL ist immer, wenn nichts angegeben ist, die von dem Path. Das heißt, man nimmt quasi Slash an, als Path für die einzelnen Methoden.

Ich kann das aber auch zum Beispiel konfigurieren. Das heißt, wenn ich Person-Slash-Advice haben will, weil ich die Adressen von Personen haben will, habe ich Slash-ID von der Person, Slash-Address zum Beispiel. Dann würde ich keine neue Ressource für aufmachen, sondern das macht man ja ganz klassisch in der Person-Resource.

Wie kommen jetzt aber noch weitere Dinge dazu? Jetzt haben wir zwei schöne Basic-URLs gebaut, aber wir wollen natürlich jetzt auch noch mehr sehen. Also wie definiere ich zum Beispiel Variablen, die ich übergeben kann. Query-Parameter von außen. Auch relativ einfach. Die werden als Funktionsparameter quasi angegeben. Und die kriegen die Annotation at query-param. Und das at query-param-Name heißt,

dass das hier als Funktionsparameter angegeben wird. Also die beiden müssen matchen. Wie die Variable heißt, das interessiert den Außen überhaupt nicht. Das heißt, wenn ich die irgendwie anders nenne, weil das intern ist, ist das für mich der Personenname oder Eklipsion, ist das egal. Wichtig ist, dass hier ist quasi genau das. Das heißt, wenn ich jetzt was mit Fragezeichen gleich Adam herunterschicke, würde hier Adam rausfallen.

Entities holen. Also ich gebe jetzt eine ID von einer Person an und will die haben. Nicht nur alle Personen. Funktioniert quasi genauso. Das ist ein Parameter. Das heißt, der wird nachher noch irgendwie gefüllt. Und der kann auch beliebig aussehen.

In diesem Fall zum Beispiel ein String sein. Dann hab ich path-param. Und dann ist halt genau die Annotation path-param, nicht at query-param, sondern weil das im Pfad dann steht, nicht als query hinten dran hängt. Eigentlich alles relativ easy. Ist nicht so kompliziert. Kann man schön verstehen. Wenn man eine gute Idee hat, er zeigt ihm das auch alles irgendwie. Genau. Das war das, was ich gerade eben erklärt hab.

Da braucht man halt immer wieder mal so einen Excel-Export. Dann gibt man hier zum Beispiel, ich glaube, Mediatype, Application, Octa-Stream an. Das heißt, dann sagt man halt, diese Ressource liefert immer Excel-Dateien zurück. Oder wenn ich eine Image-Ressource hab, die halt Bilder zurückliefern soll, warum auch immer man das durch Java durchziehen wollen würde,

dann würde man hier halt auch Mediatype-Image oder was auch mal angeben. Oder auch zum Beispiel Text zurückliefern. Oder HTML-Seiten, das geht alles. Ist dann kein Rest-API mehr, aber kann man dann trotzdem so machen. Genau. Dann kann man ja auch so ein bisschen weiterliefern, weil der Kunde unbedingt nichts im Engine-Steller braucht noch, weil er noch vielleicht noch mit dem Soap unterwegs hat. Dann kann ich halt auch sagen,

sogar einzelne Funktionen können dann quasi von diesem Default abweichen. Das ist so ein bisschen diese Interface-Gedanke. Nur, dass es hier in der Klasse ist. Wenn ich das Interface höher schreibe, habe ich der Produce-Consumens. Man kann nicht nur dann auf Klassenebene ändern, sondern eben auch auf Funktions-Ebene das Ganze nochmal modifizieren. Kommen wir zu ein paar weiteren Features. HatiOS, kennt ihr?

Kopfschütteln. HatiOS ist im Prinzip die Definition, dass die Ressourcen nicht mehr servbar sein sollen und die Maschinen nicht mehr servbar sein sollen. Das heißt, wenn ich eine Ressource zurückkriege, kriege ich weiter für eine Links mitgeliefert. Meta-Informationen. Wo finde ich die nächste Ressource, wo finde ich die vorherige Ressource, wo finde ich aber zum Beispiel auch verknüpfte Ressourcen unter welchem Endpunkt.

Das Ziel ist es, quasi möglichst diese Rest-API so automatisiert passbar zu machen, dass ich da einfach ein Tool drauf schmeißen kann. Das klickt den ersten Punkt an und das weiß dann ganz genau, ich will jetzt die nächsten zehn Ressourcen haben und das ist ein ganz einfaches Beispiel. Oder aber ich sage, ich brauche die Personen und alle Adressen dazu,

dann kriege ich aus der API raus, hey, da gibt es noch einen Links zu Address und das ist dann die andere URL, ohne dass irgendwer das lesen können müsste. Das kann ich dann automatisiert passen. Das ist eigentlich der Idealzustand, wie eine Ress-API aussehen sollte. Ich glaube, ich kenne keine, die das kann, komplett, so richtig, mit allem, aber das wäre perfekt, dann bräuchte ich quasi noch ein System dran setzen,

das liest alle URLs und kann sich komplett verabschieden. Also ich will nicht einfach irgendwie alle Rette zulassen, die man nach Händisch validieren müssen, sondern vielleicht will ich einfach sagen, das muss eine E-Mail-Adresse sein, die du da über mir übergibst und will das eigentlich nicht selber validieren, weil eigentlich gibt es Validatoren für den ganzen Spaß, halber reicht nicht davon, warum sollte ich das selber implementieren müssen.

Oder eben so Defaults, das heißt, ich habe optionale Query-Parameter, wo ich aber einen Standardwert haben will, gerade bei der Pagenierung total sinnvoll, ich sage irgendwie den Max-Wert, ich will halt nicht, dass alle Ressourcen immer überall erreichbar sind, sondern schon, dass eben auch mal ein paar Sachen

versteckt sind. Zum ersten Punkt, die Antwort quasi PIM, also HATiOS implementieren. Das brauchen wir, wir brauchen Meta-Information, wie schon gesagt links, sodass sie automatisiert gelesen werden können. Das kann so aussehen, wir haben hier das Ergebnis von Data drinstehen, die Information, wie groß ist das Ganze, die Antwortgröße

und wie viel gibt es eigentlich überhaupt. Das ist auch schon erste Meta-Information und dann gibt es da noch eine Links-Section, wo dann drinsteht, hey, die nächste Seite ist hier, die aktuelle Seite ist diese und das war jetzt die erste Seite, das ist z.B. null. Das ist ganz simples, HATiOS. Wie kriegt man das implementiert? Man baut sich Response-Klassen dafür, die dann zurückgeliefert werden,

nicht mehr das Model selber, wo halt eben noch Meta-Information dran machen, wenn man Meta-Information dransitzen kann. Das heißt, wir haben die Basic-Response, die im Prinzip nur Type-Message-Total zurückgeliefert und Status und erweitern die Links und sagen halt, das sind Stinks. Das ist eine ganz, ganz händische Methode, das zu machen.

Es gibt im Prinzip noch eine automatisierte Option, mit der habe ich aber keine Erfahrung tatsächlich, also es nennt sich Jersey-Server-Linking, die kann das mit Annotations automatisiert irgendwie bauen. Wie gesagt, habe ich aber leider keine Erfahrung, damit haben wir so bisher noch nicht implementiert. Das Ganze wird aber dann wieder, so wie wir eben auch schon gesehen, quasi bei Jersey einfach registriert,

bei der Ressourcenfig quasi wird einfach so das Linking-Feature aktiviert. Läuft bei diesen Drop-Reset-Anwendungen viel über beim Run oder beim Hochfahren, es gibt noch so eine Configure-Face quasi, registrieren von Bundles, die benutzt werden sollen zum Beispiel. Läuft richtig viel darüber. Wer weiter lesen möchte, kann gerne den Link folgen, die Slides kommen nachher auch online,

das heißt, da könnt ihr auch nochmal draufgucken. Wie sieht es mit Validatoren aus? Ich habe jetzt den Namen und sage, den möchte ich jetzt gerne validieren. Der darf zum Beispiel nicht leer sein. Ganz einfach, netnotempty, kann ich einfach eine Property dran machen. Hier mache ich das quasi einfach an den Parameter dran. Damit prüft automatisch,

wenn der Request kommt, Drop-Reset, hey, das ist leer, kriegst sofort eine Fehlermeldung zurück, von wegen unprocessable entity zum Beispiel oder eben andere sinnvolle Fehlermeldungen. Die Klasse sind die Validatoren, die man so kennt von Hibernate, Note Null, min, max oder den Size-Parameter, also in range. Dann gibt es auch noch so future and past für Daten. Man kann Requestes angeben

und auch einfach invalid, dieses Objekt muss valid sein und dann geht er quasi in das Objekt rein, prüft, welche Validatoren gibt es eigentlich und validiert das Ganze dann. Wie sieht Authentizierung aus, Drop-Reset? Es gibt Authenticators, die man schreiben kann, das ist jetzt ein einfaches Beispiel. Der kriegt quasi Credentials

und prüft, sind dann die Credentials also richtig. In diesem Fall würde er prüfen, da ist das Passwort Secret, also heißt das Passwort Secret und wenn dem so ist, dann gibt ein User zurück, der will jetzt eine Authentication haben, automatisch dazu führt, dass ein 401 kommt, verbinden, darfst du nicht rein.

Das heißt, man muss einmal so einen Authenticator schreiben, da gibt es schon sehr viele vorgefertigt von, also Basic Auth ist klar, es gibt auch für Auth2 schon einen Authenticator, wenn man also so einen Token quasi übergibt, alles drin, genau, das muss einmal an dieser Stelle quasi auch wieder, wie vorhin schon gesagt, registriert werden in der Main-Klasse

als Example Authenticator, dann segelt wird noch ein Realman, der aufpoppt, wenn man so, man kennt das ja, wenn du so eine Ressource aufmachst, die quasi geschützt ist, kriegst du dann immer aufgepoppt hier, Gürtige geben dir Credentials ein, bei Basic Auth zum Beispiel, damit jetzt super Secret Staff auftauchen und dann registrierst du das einmal. Und dann ist das Einzige,

was tatsächlich zu tun ist, im Code ist hier so ein Funktionsparameter hinzuzufügen, der die Ad-Auth-Annotation hat. Ad-Auth heißt, hey, das hier ist die Authorisierungsinformation geschützt, das heißt, da kommst du nicht mehr rein ohne Passwort. Und das ist alles, das heißt, ich brauch darunter kein Handling mehr zu machen, hat der User ein gültiges Passwort eingegeben,

gibt's den User, das schreib ich alles in die Authenticator rein und dann wird das einfach mal quasi hier durch die Ad-Auth reingelesen, geprüft und dann, wenn es, wie gesagt, invalide ist, sofort raus, kommst du sofort raus, dann kommst du gar nicht in den Code rein, der da unten drunter ist, sondern gehst sofort zurück, das heißt, das Server verarbeitet gar nichts großartig

und das ist immer, das ist zwingend benötigt, das ist keine optionale Authorisierung, sondern das ist immer zwingend da. Das zum Jobresort, erst mal Fragen zu dem Teil. Wir gehen jetzt weiter zu Svega. Alle erschlagen, alle eingeschlafen. Es ist in öffentlicher Verfügung

das Paket, open source, das ist nicht von uns, da haben wir quasi nichts mit zu tun, wir benutzen das nur. Die Webseite kommt auch gleich in Jobresort.io, da kann man sich das alles schön angucken auch. Genau, was macht Svega? Svega bietet eine ganz einfache Anleitung von Rest-APIs an, sie es ermöglicht, weil es ein JSON ist, was erzeugt ist,

automatische SDK-Generation, also wenn ich JSON lesen kann, daraus quasi Code generieren kann, kann ich das machen. Und es liefert mit Svega UI zusammen, das ist der Bonuspart noch ein schönes User-Interface, wo man klicken und angucken kann und lesen kann, was für einen User immer sehr wichtig ist, für eine Maschine vollkommen egal, was für uns total spannend ist. Das heißt, von unserer alten Anwendung, wir haben jetzt eine neue mittlerweile gebaut,

das heißt, wir bauen unseren Code normal durch, machen in der nächsten Aushalt die Annotationen dran und dann fällt hier der ganze Spaß raus. Das heißt, da steht hier drin, das ist die APV1, welche Header zum Beispiel möglich sind und dann sieht man hier zum Beispiel in diesem Fall Business Capabilities ist die Ressource und da gibt es jetzt ein Get, Post, Put, Delete,

Get, Post, Post, Put, Delete Funktionen, jeweils mit IDs und ohne und im Prinzip eine ganz schöne Dokumentation. Und sowas einfaches bauen wir jetzt auch gleich noch kurz mal zusammen. Wie funktioniert das Ganze? Die Code Annotations werden von Svega interpretiert, das ist ein JSON-Case, also ein JSON-File nachher rausgeworfen und mit diesem JSON-File kann man entweder wie gesagt diese

UI bauen, das macht Svega UI oder halt eine SDK generieren. Gibt es auch eine Svega SDK Tool, was halt SDKs wirklich für fast jede beliebige Programmiersprache generiert. Das heißt, wenn du einen C Sharp brauchst, obwohl das Programm ein Java-Geschirm ist, kann ich den C Sharp SDK machen oder halt auch, ich glaube wir haben C Sharp, PHP und halt Java, klar. Und ich glaube noch ein paar mehr.

Ich meine Python geht auch, ja. Da brauchen wir nicht mehr viel dran zu machen. Du kannst aber, wenn du willst, bei der SDK-Generierung noch selber Klassen hinzufügen, die du haben willst. Also du kannst Templates anlegen, wo du sagst, die will ich unbedingt drin haben, weil ich jetzt eine Sonderfunktion oder Rapperfunktion schreiben will, das kannst du dann selber noch dazu tun. Aber der ganze sonstige Code kann automatisch generiert werden.

Also werden Klassen erstellt, die du einfach benutzen kannst, API-Klassen. Du kannst das Paket bei dir inkludieren, kannst es einfach benutzen. Jetzt haben wir unseren Code hier. Jetzt ziehe ich mal, wo ist es da?

Mein zweites Fenster rein. So, das ist im Prinzip das Gleiche, was wir da eben schon gesehen haben. Wir haben unser Model Person, die Ressource gibt es hier schon. Die Ressource hat nur jetzt, wie wir sehen, die Funktion, die ich gerade eben schon mal erwähnt habe. Also wir haben jetzt quasi diese Get-Funktion, die wir ursprünglich gesehen haben. Und da habe ich halt noch ein paar

weitere Funktionen zugefügt. Das ist mit einem Fastest. Das kann ich also suchen, habe einen Query-Parameter, der übergeben wird, der in diesem Fall Q heißt. Und der wird dann einfach übergeben. Die geben hier nichts Sinnvolles zurück. Das ist auch klar. Es hat ein kleines Demoprogramm. Aber man sieht halt im Prinzip, wie es funktioniert. Keine Besonderheit dabei.

Alles Fast-Parameter haben wir hier unten noch mal als ID. Das ist quasi alles, was hier zu tun ist. So. Was gibt es in der Config-Yammer? Das ist die Konfigurationsartikel, die ich gezeigt habe.

Habe ich hier mal ein paar Ports schon mal definiert. Das heißt, ich habe Swagger gesagt, guck mal, wir haben die Ressourcen, die liegen hier unter Linux-Frostcon. Da gibt es Ressourcen-Packages, damit er weiß, wo er suchen muss. Er sucht dann automatisch auch in den Resource-Ordner. Und ich sage ihm halt, hey, das Ding ist jetzt unter port 1337 zu erreichen und nicht mehr unter port 8080.

Gehen wir mal wieder unsere Anwendung rein. Also müssen wir jetzt Frostcon 2 machen. Und außerdem, was ihr gesehen habt, geändert, ich habe noch keine Annotationen hinzugefügt. Überziehe ich gerade passiv? Eigentlich nicht, ne? So. Bau das Ganze mal eben kurz.

So, ist auch fertig. Und läuft das gleiche wie gerade eben. Server. Target. Frostcon. Nee. Das müsste Frostcon-Test heißen. Genau.

Also, hey, da gibt es eine Konfigurationsdatei, die du bitte ausliest, damit das Ganze ankommt. Jetzt startet das Ganze. Im Prinzip genauso wie vorher. Wir sehen hier, wir haben jetzt mehr Endpunkte, klar, die ich alle definiert habe. Eine Get-Ressource, PostPort, Get-Elite. Und, ich gucke mal, ob das hier auch... Genau, und wir sehen hier, das ist eine Ressource, die habe ich

derweil gar nicht definiert, nämlich den Swagger-Ressource aufgetaucht. Das heißt, es gibt eine Ressource, die heißt Swagger. 1, 3, 3, 7. Und machen Swagger auf. So, jetzt sehen wir, jetzt haben wir schon mal ein Swagger-UI, aber wir kriegen noch eine Fehlermeldung.

Das heißt, wir haben am Anfang jetzt, wir haben jetzt erstmal noch einen Fehler, weil wir in Swagger noch gar nicht gesagt haben, wie unsere Ressource eigentlich aussieht. Das heißt, Swagger hat jetzt zwar gesehen, ja, da gibt es eine Ressource, aber so richtig was damit anfangen konnte, ist jetzt gerade noch nicht. Das heißt, wir müssen jetzt noch ein paar kleine Annotationen zufügen, damit wir

noch ein paar kleine Annotationen dazu. Das erste, was wir machen, ist sagen, hey, das Ding ist eine API, und die Ressource, die wir haben wollen, warte mal, das Value heißt das Ding, heißt Person. Persons.

So, das ist der einzige Stück Code, den ich geändert habe, und jetzt kompilieren wir das Ganze neu, und dann machen wir die Seite nochmal auf. So, einmal kompiliert, einmal laufen lassen. So, ist fertig gebaut. Und jetzt laden wir die Seite nochmal

auf die Annotation. Also, da steht keine Information, aber ich habe jetzt quasi ein clickablees Interface, da sind jetzt quasi die Personenressource dabei, ich habe einen get-end-Punkt, post-put-end-Punkt, und ich kann auch einfach hier mal auf try-out klicken. Also, ich mache das gerade mal ein bisschen größer, damit die Quants zu lesen sind, oder?

Wahrscheinlich geht es jetzt der Style-Flöten. Genau, jetzt kriege ich auf try-out, und jetzt kriege ich hier eine Antwort und das kann ich jetzt mit den Ressourcen machen, die ich quasi da habe. Das heißt, da ich jetzt hier keine Autorisierung oder irgendwas davor geschaut habe, kann ich jetzt einfach probieren, ich kann hier auch

Testwerte gegenwerfen, das heißt, ich kann auch sagen, also um zum Beispiel für mich auszubringen, funktioniert das hier, kann ich den Personen übergeben, dann sage ich hier so, ich sage jetzt hier irgendwo Foo und Bein, wie wir das so machen, gucken, gucken, ob ich

da eine Validierung drauf gesetzt habe. Und er sagt so, alles gut, und die Antwort kommt zurück. Also ich habe keine Validierung auf E-Mails gemacht, sonst hätte ich direkt eine Exception gekriegt, hätte ich gesagt, hey Junge, das muss eine E-Mail sein, und so kann ich halt bei der AP einfach ausprobieren. Ich habe noch nichts gemacht, ich habe nur eine Annotation zugefügt.

Jetzt sieht man aber auch natürlich, das ist, wenn jemand versucht zu verstehen, was da passiert, ist das nicht so geil, weil es gibt Aber man kann das jetzt noch anreichern mit Daten. Und dafür genutzt man einfach

weiter diese AP-Annotation. Das heißt, wenn wir jetzt zum Beispiel GetPerson anreichern wollen durch Informationen, dann kommt die AP-Operation dabei. Und hier kann ich einfach noch definieren, zum Beispiel den Text, der da nachher steht, zum Beispiel Get a Single Person. So.

Und dann kann ich ihm auch noch angezeigt werden. Das heißt, hier kann ich dann immer noch weitere Dokumentationen dazu schreiben. Zum Beispiel.

Ich mache jetzt gerade mal direkt noch ein bisschen weiter, damit wir nicht nur eine Änderung sehen. Bei den Parametern kann ich auch Dinge hinzufügen, das ist dann AD-AP-Param. Also hier. Und folgt dem gleichen Muster. Das ist aber jetzt der Punkt, wo man schon den ersten, ich

nenne ihn, Required-Parameter. Und das ist, das soll eigentlich die Person sein, die wir finden wollen. Und wenn ich ins Value schaue, wenn ich value, passiert mir mal ein Blindtipp hier.

Gucken wir mal, ob was Interessantes daran zufügen soll. Eigentlich nicht. Doch, genau, wir können noch hinten noch, das ist aber alles gut. Ne, dann passt das. Genau. Und dann bauen wir das Ganze einmal wieder kurz neu und dann haben wir unsere lustige Dokumentation daran. Also einmal ein neues Package bauen. Das bauen ist sehr nötig, weil das nicht on the fly ändern kann. Klar wäre, dass das im Code

ausliest. Ja klar. Ich meine, das wird aus dem Jar ausgelesen, muss also mit eingebaut werden. Dann fahren wir wieder hoch. Gehen wir mal dahin. Und sehen jetzt zum Beispiel, dass jetzt, wenn alles gut gelaufen ist. Gucken wir mal. Genau, da sehen wir zum Beispiel hier, dass jetzt mehr Informationen gekommen sind. Das heißt, es steht hier oben

zum Beispiel daran hier, das gibt mir eine Single Person zurück und da sind unsere Notes angegeben, die wir angegeben haben und beim Search steht jetzt am Suchparameter auch dann, was hier eigentlich zu suchen ist. Und es steht vor allem auch dran hier, da muss er angeben. Kannst du nicht einfach so weglassen, es steht required drin. So kann man halt einfach mit durch weitere Annotationen das Ganze noch anreichern, einfach

noch mehr umfangreiche Dokumentation schaffen. Wobei im Prinzip ja die Ursprungsversionen, wo ich mit einfachen AP, wo ich heiße Ressource, würde in einer Maschine vollkommen ausreichen. Damit sehe ich quasi einen Code, kann den Kanäle einpunkten, kann entsprechend mich weiter durch dagegen bewegen. So, dann gehen wir weiter im Text.

So, das heißt also die Basic Annotations haben wir gesehen. At AP, wie heißt meine Ressource? Ich kann sagen, die Responses definieren, ich kann zum Beispiel sagen, das liefert 403 zurück, wenn du irgendwie nicht die richtigen Credentials hast oder 404, wenn es nicht gefunden werden kann, was du gesucht hast, was auch nützliche Informationen passt,

wenn ein Nutzer ist, kann auch mehr als eine nicht definieren, Die Operation Value and Nodes haben wir gesehen. Ich kann auch sagen, was für eine Cluster kommt eigentlich zurück. Das kann ich ja auch explizit sagen, also wenn ich eine bestimmte Response-Klasse habe, wenn das vernünftig zurückliefert und wie der Container heißt. Das haben wir auch gesehen, AP-Parameter und man kann ja auch noch die Default-Value, die wird quasi auch

interpretiert, wenn ich die angebe, von Zweigern, damit ihr mir das auch einen Trick dann zeigt. Noch ein paar schöne Sachen. Default-Value required haben wir gesehen. Allowable-Values, wenn ich ein Beispielstring habe oder sage, ich habe Swings, die müssen ein bestimmtes Format haben, damit die funktionieren und ich will kein Validator dafür schreiben, was trotzdem sinnvoll ist, kann ich auch noch sagen, hier Allowable-Values, ein

Beispielstring angeben und ich kann auch noch sagen, ist das versteckt oder nicht in der API. Es gibt Parameter, die will man vielleicht nicht nach außen rausgeben, weil es lieber Parameter oder ähnliches sind. Die sind ja zwar immer noch erreichbar, aber die tauchen in der API dann nicht auf. Also wenn ich das in ein User oder so etwas rausgeben möchte zum Beispiel. So, die Models kann man auch noch annotieren, da kann man auch noch dran schreiben, was sie alles so können, genauso die Properties und noch

Contact und Licenses kann man angeben. Die erweiterten Features kann man sich hier mal angucken, also wir haben einen Swagger-Demo-Code-Gen-Projekt, wo man sich das angucken kann, wie das funktioniert, dass wir aus dem Swagger-Code automatische SDKs bauen und die Konfiguration dafür ist unter dem Link verfügbar. Den konnte ich vorher nicht testen, weil ich keine Intelligen mehr hatte.

Und das war es auch von mir schon. Die Stunde, die dreiviertel Stunde ist um, ihr seid noch alle wach, hoffentlich. Gibt es Fragen? Jetzt noch. Ja. Roles und ACL musst du

selber implementieren. Das macht Drupal so nicht. Du könntest es vielleicht in den Authenticator mit einbauen, dann wären die Authenticator natürlich riesig groß. Aber ACL ist eh relativ kompliziert, deswegen wirst du ihr eigene Klasse dafür schreiben. Wir haben, wo wir bei uns ACL implementiert haben, das selber gemacht. Wir haben dann Shiro genutzt quasi als Aufsatz da drauf und nutzen das aber glaube ich auch im Authenticator, also in diesem, dass der im Authenticator auch direkt

das Shiro quasi aufruft und testet, hey, was darf der User eigentlich? Zumindest gucken, ob er überhaupt rein darf.

Das ist richtig, aber die Komplexität kommt ja aus der Business zurück, die du hinter schreibst. Deswegen, also, das kostet im Prinzip keine großartige Zeit und auch keine Ressourcen, diese AP zu dokumentieren, zu erstellen, der, was nachher Zeit kommt, wo du Skalierpower für

brauchst, ist der Code, Ja, aber kannst du die Frage noch konkreter formulieren, der Skalierung? Also, natürlich, ja. Nee, nee, das kannst du so produktiv nehmen.

In unserem Setup läuft das so, dass wir diese, diese Ja-Files nehmen, die werden in einen Docker-Container reinkopiert, quasi. Im Runscript steht genau dieses Teile Code drin, die ihr habt, die ihr habt, davor noch ein bisschen Vorverarbeitung, und dann wird der Container einfach hochgefahren. So, dann hat sich die Sache. Und über den Variabeln, die der Container kriegt, hast du alles konfiguriert, was du brauchst. Und that's it. That's it. Das ist also mega simple.

Es gibt auch noch eine Alternative zu Drop Wizard, das ist Spring, Spring Boot. Ich hab noch keinen seriösen Vergleich zwischen beiden gesehen, wo, gesagt, wo das eine ist besser als das andere. Spring Boot heißt das Projekt. Ich glaube, wir haben damals mit Drop Wizard angefangen, deswegen ist das für uns das Tool der Wahl. Spring Boot oder Spring ist genauso gut. Also, würde ich jetzt so aus meinem Standpunkt sagen für jemanden, der keine Ahnung, keine richtige Ahnung von Spring Boot hat.

Ich glaube, ich würde schätzen, ja, weil Swagger im Prinzip unabhängig von der, von der, von der Technologie, die da drunter ist, sondern Swagger ist nur darauf angewiesen, dass es quasi, dass du diese Swagger-Klassen einbindest, und ich meine, die gibt es auch nicht nur für Java. Also, die kannst du auch, und auch für Spring wahrscheinlich benutzen. Weil Swagger lebt ja eigentlich von den Annotationen, von den Annotationen, die kommen ja aus dem Swagger-Paket

selber raus. Das wird, je nachdem, wie es eingestellt ist, wird das entweder beim Package-Generieren quasi erzeugt, oder es geht on the fly. Package-Generieren ist eigentlich so das, wo wir das eher machen, weil im Endeffekt ändert sich der Code danach nicht mehr. Du kannst da natürlich,

wenn du jetzt im Live-Coding bist, gerade im Debug-Modus, und du änderst die Annotation, ändert sich das dann auch nicht, aber das ist, glaube ich, für den Fall auch nicht nötig. Also, bei uns ist es, glaube ich, auch so, dass es beim Clean, beim Package-Prozess quasi, also beim Package wird das Ganze damit gebaut, erzeugt und die JSON einfach hingelegt, damit die dann wirklich statisch gesurft, und dann kannst du sie auch unter anderem, unter anderen URL zu den IT-Erreichbar machen. Das ist auch übrigens kein Problem.

Nee, die URL muss nicht immer Swagger heißen, die kann auch Docs oder Api-Docs oder wie auch immer heißen, das kann man dann beliebig konfigurieren, wie man das möchte. Ja. Ich habe keine Hands-on, ich habe Spring Boot noch nicht benutzt, deswegen, aber ich habe mich immer ein bisschen, wo ich mir das angefangen habe,

mit dem Fortran vorzubereiten, mal ein bisschen schlau gelesen, was du baust. Also, was ich so gelesen habe, ist halt, dass du mit JobReset relativ kleine Services ganz gut bauen kannst, und mit Spring Boot baust du größere Dinge. Aus meiner persönlichen Erfahrung kann ich aber sagen, wir können auch mit JobReset sehr große, gute Dinge bauen. Also wir bauen auch Services, die nicht klein sind, zwingen, das müssen nicht Markerservices sein,

sondern auch, sind einfach manchmal Rest-Services, und wir haben noch nie irgendwie Performance-Probleme gesehen damit, die aus JobReset herausrühren, weil am Ende des Tages, die Technologien, die dahinter sind, alle schwer erprobt. Ich meine, Jersey und Jetty, alles nichts Neues. Also deswegen, ich weiß nur, dass Spring Boot einfacher aufzusetzen ist, tatsächlich, wenn du noch Sachen hinzuhaben willst, weil du ja mittlerweile eine Konfigurations-Interface hast.

Das habe ich mal im Talk gesehen, wo du einfach klicken brauchst, und dann hautest du dir noch automatisch die Dependencies rein. Das ist vielleicht der einzige Vorteil, den man noch hat, wenn man wirklich speziellere Wünsche noch hat. Okay, dann wie gesagt, vielen Dank. Wir hiringen, ich muss immer noch dazu sagen.

Quellen kommt alles, und die Slides kommen sowohl bei der Frostcon hoch, als auch unter Slideshelf auf unserem News Account, dass ihr da nochmal draufschauen könnt. Ja, dann, schönen Tag noch.