{"id":38022,"date":"2019-10-31T22:21:14","date_gmt":"2019-10-31T19:21:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/tak-vse-taki-raml-ili-oas-swagger\/"},"modified":"2019-10-31T22:21:14","modified_gmt":"2019-10-31T19:21:14","slug":"tak-vse-taki-raml-ili-oas-swagger","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/tak-vse-taki-raml-ili-oas-swagger","title":{"rendered":"Also, RAML oder OAS (Swagger)?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

In der dynamischen Welt der Mikrodienste kann sich alles \u00e4ndern \u2013 jede Komponente kann in einer anderen Sprache, mit anderen Frameworks und Architekturen neu geschrieben werden. Lediglich die Vertr\u00e4ge m\u00fcssen unver\u00e4ndert bleiben, damit der Mikrodienst von au\u00dfen auf einer konstanten Grundlage angesprochen werden kann, unabh\u00e4ngig von internen Metamorphosen. Und heute werden wir \u00fcber unser Problem bei der Auswahl des Formats zur Beschreibung von Vertr\u00e4gen sprechen und die gefundenen Artefakte teilen. <\/p>\n

\"Also,
\n<\/a><\/noindex>
\nBeitrag verfasst von Anna Melehkova<\/a><\/noindex> und Vladimir Lapatin<\/a><\/noindex> <\/p>\n

Mikrodienste.<\/b> Bei der Entwicklung von Acronis Cyber Cloud haben wir erkannt, dass wir nicht um sie herumkommen. Das Design eines Mikrodienstes ist ohne Formalisierung des Vertrags, der das Interface des Mikrodienstes darstellt, unm\u00f6glich.<\/p>\n

Doch wenn im Produkt mehr als eine Komponente enthalten ist und die Entwicklung des Vertrags zu einer regelm\u00e4\u00dfigen T\u00e4tigkeit wird, beginnt man unweigerlich \u00fcber die Optimierung des Prozesses nachzudenken. Es wird offensichtlich, dass das Interface (Vertrag) und die Implementierung (Mikrodienst) zueinander passen m\u00fcssen, dass verschiedene Komponenten dieselben Dinge gleich machen sollten und dass ohne eine zentrale Entscheidung \u00fcber all diese Aspekte jedes Team gezwungen sein wird, immer wieder Zeit f\u00fcr deren Kl\u00e4rung aufzuwenden. <\/p>\n

\"Also,
\nDas Schema der Mikrodienste von Amazon aus einem Tweet<\/a><\/noindex> von Werner Vogels, CTO von Amazon<\/i>
\nWorin besteht also das Dilemma? De facto gibt es zwei M\u00f6glichkeiten, wie Mikrodienste miteinander interagieren \u2013 HTTP Rest und gRPC von Google. Um nicht in den Technologiestack von Google involviert zu werden, haben wir uns f\u00fcr HTTP Rest entschieden. Die Annotations f\u00fcr HTTP REST-Vertr\u00e4ge werden in der Regel in einem der beiden Formate beschrieben: RAML und OAS, fr\u00fcher bekannt als Swagger. Daher sieht sich jedes Entwicklerteam mit der Notwendigkeit konfrontiert, sich f\u00fcr einen der Standards zu entscheiden. Aber wie sich herausgestellt hat, kann diese Wahl sehr schwierig sein.<\/p>\n

Warum sind Annotations erforderlich?<\/h3>\n

\nEine Annotation ist notwendig, damit externe Benutzer leicht verstehen k\u00f6nnen, was sie \u00fcber die HTTP-Schnittstelle mit Ihrem Service tun k\u00f6nnen. Auf einer grundlegenden Ebene sollte die Annotation mindestens eine Liste der verf\u00fcgbaren Ressourcen, deren HTTP-Methoden, Anfragek\u00f6rper, eine Auflistung von Parametern sowie die Angabe von erforderlichen und unterst\u00fctzten Headern sowie R\u00fcckgabecodes und Antwortformaten enthalten. Ein \u00e4u\u00dferst wichtiges Element der Vertragsannotation ist auch ihre verbale Beschreibung (\u201eWas passiert, wenn dieser Query-Parameter zur Anfrage hinzugef\u00fcgt wird?\u201c, \u201eWann wird der Code 400 zur\u00fcckgegeben?\u201c)<\/p>\n

Dennoch, wenn es um die Entwicklung einer gro\u00dfen Anzahl von Mikrodiensten geht, m\u00f6chte man zus\u00e4tzlichen Nutzen aus den verfassten Annotationsgenerieren. Beispielsweise kann man basierend auf RAML\/Swagger nicht nur Client- sondern auch Servercode in einer Vielzahl von Programmiersprachen generieren. Au\u00dferdem kann man automatisch Dokumentationen f\u00fcr den Mikrosdienst erhalten und diese auf Ihrem Entwicklerportal hochladen : ).<\/p>\n

\"Also,
\nBeispiel f\u00fcr eine strukturierte Beschreibung des Vertrags<\/i><\/p>\n

Seltener wird die Praxis des Testens von Mikrodiensten basierend auf Vertragsbeschreibungen angewandt. Wenn Sie sowohl die Annotation als auch die Komponente erstellt haben, k\u00f6nnen Sie einen automatisierten Test erstellen, der die Angemessenheit der Funktionsweise des Service mit verschiedenen Datentypen als Eingabe \u00fcberpr\u00fcft. Gibt der Service einen nicht in der Annotation beschriebenen Antwortcode zur\u00fcck? Kann er absichtlich falsche Daten korrekt verarbeiten?<\/p>\n

Dar\u00fcber hinaus vereinfacht eine qualitativ hochwertige Umsetzung nicht nur der Vertr\u00e4ge, sondern auch der Werkzeuge zur Visualisierung der Annotationsarbeit mit Mikrodiensten. Das hei\u00dft, wenn der Architekt den Vertrag qualitativ beschreibt, werden Designer und Entwickler auf dessen Grundlage den Service in andere Produkte integrieren, ohne zus\u00e4tzliche zeitliche Aufw\u00e4nde.<\/p>\n

F\u00fcr die Arbeit mit zus\u00e4tzlichen Tools bieten sowohl RAML als auch OAS die M\u00f6glichkeit, Metadaten hinzuzuf\u00fcgen, die nicht im Standard vorgesehen sind (zum Beispiel, so wird es in OAS gemacht<\/a><\/noindex>).<\/p>\n

Im Allgemeinen gibt es im kreativen Umgang mit Vertr\u00e4gen f\u00fcr Mikrodienste viel Spielraum\u2026 zumindest theoretisch<\/p>\n

Ein Vergleich von Igels und Schlangen<\/h3>\n

\nDerzeit ist die Entwicklung der Acronis Cyber Platform die Priorit\u00e4t bei Acronis. Die Acronis Cyber Platform bietet neue Integrationspunkte f\u00fcr Drittanbieter-Services mit Acronis Cyber Cloud und der Agentenkomponente. W\u00e4hrend unsere internen APIs, die in RAML beschrieben sind, f\u00fcr uns zufriedenstellend waren, hat die Notwendigkeit, APIs zu ver\u00f6ffentlichen, erneut die Frage aufgeworfen: Welcher Standard f\u00fcr Annotations ist am besten f\u00fcr unsere Arbeit geeignet?<\/p>\n

Urspr\u00fcnglich schien es zwei L\u00f6sungen zu geben \u2013 die am weitesten verbreiteten Entwicklungen RAML und Swagger (oder OAS). Tats\u00e4chlich stellte sich jedoch heraus, dass es mindestens nicht zwei, sondern drei oder mehr Alternativen gibt.<\/p>\n

Einerseits gibt es RAML \u2013 eine leistungsstarke und effiziente Sprache. Die Hierarchie und Vererbung sind gut umgesetzt, sodass dieses Format besser f\u00fcr gro\u00dfe Unternehmen geeignet ist, die viele Beschreibung ben\u00f6tigen \u2013 also nicht ein Produkt, sondern viele Mikrodienste, die gemeinsame Teile von Vertr\u00e4gen haben \u2013 Authentifizierungs-Schemas, identische Datentypen, Fehlerk\u00f6rper.<\/p>\n

Der Entwickler von RAML, die Firma Mulesoft, hat sich dem Open API Consortium angeschlossen, das sich mit der Entwicklung besch\u00e4ftigt Swagger<\/a><\/noindex>. Daher hat RAML seine Entwicklung eingestellt. Um sich das Veranstaltungsformat vorzustellen, kann man sich vorstellen, dass die Wartungsmitarbeiter der Hauptkomponenten von Linux zu Microsoft gewechselt sind. Eine solche Situation schafft die Voraussetzungen daf\u00fcr, Swagger zu nutzen, das dynamisch entwickelt wird und in der letzten \u2013 dritten Version \u2013 nahezu mit RAML in Bezug auf Flexibilit\u00e4t und Funktionalit\u00e4t Schritt h\u00e4lt.<\/p>\n

W\u00e4re da nicht ein Aber...<\/h3>\n

\nWie sich herausstellte, haben l\u00e4ngst nicht alle Open-Source-Tools auf die Version OAS 3.0 aktualisiert. F\u00fcr Mikrodienste in Go ist das Fehlen einer Anpassung go-swagger<\/a><\/noindex> an die neue Version des Standards am kritischsten. Doch der Unterschied zwischen Swagger 2 und Swagger 3 ist enorm<\/a><\/noindex>. Beispielsweise haben die Entwickler in der dritten Version:<\/p>\n