Das ist ja ein gro\u00dfer Worthappen! Lassen Sie uns SmartBears Beschreibung in kleinere H\u00e4ppchen aufteilen:<\/p>\r\n
1. \u201c\u2026definiert einen Standard\u2026\u201d:<\/strong><\/p>\r\n 2. \u201c\u2026eine sprache-agnostische Schnittstelle zu RESTful APIs\u2026\u201d:<\/strong><\/p>\r\n 3. \u201c\u2026, der es Menschen und Computern erm\u00f6glicht, die F\u00e4higkeiten des Dienstes\u2026\u201d:<\/strong><\/p>\r\n 4. \u201c\u2026ohne Zugriff auf Quellcode, Dokumentation oder durch Netzverkehrspr\u00fcfungen.\u201c<\/strong><\/p>\r\n Die Urspr\u00fcnge von OpenAPI beginnen mit dem Ingenieur Tony Tam von der Firma Wordnik im Jahr 2009. Tony erstellte eine Spezifikation (damals Swagger genannt), die Wordniks Online-W\u00f6rterbuch JSON API beschreibt.<\/p>\r\n In den n\u00e4chsten Paar Jahren machte Swagger mehrfach von Tony geleiteten Iterationen durch. Allerdings hat Swagger 2.0 einen Anstieg bei der Annahme der Spezifikation festgestellt und die Schaffung von Werkzeugen zur Analyse der Spezifikation ausgel\u00f6st.<\/p>\r\n Im Jahr 2015 wurde Swagger von SmartBear erworben. SmartBear ist das Unternehmen, das derzeit Swagger besitzt. Die Swagger-Spezifikation wurde in \u201eOpenAPI\u201c umbenannt, um die neue OpenAPI-Initiative zu reflektieren. Diese Umbenennung ist der Grund, warum \u201eSwagger\u201c mit dem \u201eOpenAPI\u201c-Standard verwechselt wird.<\/p>\r\n Zu dieser Zeit erkannte eine Unternehmensgruppe, dass die Branche eine herstellerneutrale und standardisierte Art der Beschreibung von APIs ben\u00f6tigt. Die Branche musste der Branche \u201eBest Practices\u201c anbieten und Updates f\u00fcr OpenAPI im Laufe der Zeit \u00fcberwachen.<\/p>\r\n Diese Unternehmen gr\u00fcndeten die OpenAPI Initiative als Governance-Programm unter der Linux Foundation, die den OpenAPI Standard pflegt und praktische Anleitung bietet. Die Gr\u00fcndungsfirmen, die die OpenAPI Initiative gr\u00fcndeten, waren CapitalOne, PayPal, SmartBear, IBM, 3Scale, Google, Apigee, Intuit, Microsoft und Restlet. Seitdem ist die Zahl der an der Initiative beteiligten Unternehmen erheblich gestiegen.<\/p>\r\n Der Technische Lenkungsausschuss verwaltet nun OpenAPI und ver\u00f6ffentlicht weiterhin neue Versionen basierend auf Community-Feedback.<\/p>\r\n Es gibt mehrere Spezifikationen, die RESTful APIs beschreiben. OpenAPI geh\u00f6rt zu den bekanntesten und am weitesten verbreiteten Anwendungen. Die anderen beiden Formate, die f\u00fcr REST-APIs verwendet werden, sind RAML und API Blueprint. Sp\u00e4ter werden wir die Vor- und Nachteile von OpenAPI im Vergleich abdecken. W\u00e4hrend OpenAPI als Industriestandard betrachtet werden kann, w\u00e4hlen Unternehmen am Ende oft das Format, das ihren gesch\u00e4ftlichen Bed\u00fcrfnissen am besten entspricht.<\/p>\r\n Daher stellt sich die Frage: wenn es mehrere Formate gibt, um REST-APIs zu beschreiben, warum ist OpenAPI so besonders? Ein Schl\u00fcsselfaktor daf\u00fcr, warum OpenAPI so beliebt ist, ist seine Annahme. Mehr Adoption f\u00fchrt zu mehr Unterst\u00fctzung durch die Gemeinschaft, zu robusterenInstrumenten und einer effektiveren Kontrolle.<\/p>\r\n Ein Unternehmen kann die Open API-Spezifikation f\u00fcr seine Portabilit\u00e4t und Einfachheit verwenden. OpenAPI ist \u201elanguage-agnostic\u201c und definiert eine gemeinsame Sprache f\u00fcr die Client-Server-Kommunikation. Es ist sehr kompatibel mit Systemen, die in verschiedenen Programmiersprachen geschrieben sind. OpenAPI ist auch f\u00fcr Menschen und Computer sehr lesbar und hat die Unterst\u00fctzung einer gro\u00dfen, wachsenden Gemeinschaft.<\/p>\r\n Ein weiteres beliebtes Format ist RAML, eine API-Modellierungssprache, die sich auf API-Definition und -Design konzentriert (obwohl man APIs mit OpenAPI entwerfen kann). Die Funktionen von RAML k\u00f6nnten als Zwerge von OpenAPI erscheinen. Es hat den Vorteil, hierarchisch zu sein und Datenmodellvererbung zu unterst\u00fctzen. RAML ist jedoch nicht so weit verbreitet wie OpenAPI. Obwohl RAML eine engagierte Community hat, hat es weniger Unterst\u00fctzung f\u00fcr die Gemeinschaft. RAML hat Werkzeuge, aber es gibt einige Hinweise, dass bei der neuesten Version die notwendige Unterst\u00fctzung fehlt.<\/p>\r\n Zus\u00e4tzlich zu RAML ist API Blueprint eine weitere Alternative zu OpenAPI. API Blueprint konzentriert sich auf klare Dokumentation, die sich im Gegensatz zu JSON (wie OpenAPI) oder YAML (wie OpenAPI und RAML) auf Markdown Format st\u00fctzt. Aufgrund seiner geringen Annahme fehlt es API Blueprint an Unterst\u00fctzung f\u00fcr die Community und an robusten Werkzeugen f\u00fcr OpenAPI. Die Integration der API Blueprint in Ihren gesamten API-Lebenszyklus ist schwierig, da der einzige Schwerpunkt auf Dokumentation liegt.<\/p>\r\n Zusammenfassend ist OpenAPI der beliebteste Standard f\u00fcr die Beschreibung von APIs. Obwohl es Nachteile hat, wird OpenAPI wahrscheinlich in der Annahme wachsen, w\u00e4hrend die langfristige Lebensf\u00e4higkeit anderer Spezifikationstypen unsicher ist.<\/p>\r\n Denken Sie an ein Legacy-Spezifikationsdokument, das Sie im Format Microsoft Word (.docx) lesen w\u00fcrden. Dieses Dokument stellt den breiten Kontext eines Systems dar und beschreibt seine Komponenten und Interaktionen mit anderen Systemen.<\/p>\r\n Die Struktur der alten Spezifikationen ist oft unterschiedlich. Eine API-Spezifikation, wie OpenAPI, ist streng strukturiert. Wenn eine API-Spezifikation einem anderen Format entspricht, wie RAML oder API Blueprint, hat die Dokumentation eine Struktur, die diesem Format entspricht.<\/p>\r\n Wenn Sie auf die Definition von OpenAPI zur\u00fcckkommen, h\u00f6ren Sie oft die synonymen Begriffe \u201eSpezifikation\u201c und \u201eDefinition\u201c. Eine API-Spezifikation definiert eine API. Beim Lesen einer API-Spezifikation erfahren Sie, welche Art von Anfragen Sie senden k\u00f6nnen und welche Antworten Sie von der API erhalten m\u00f6chten. Zus\u00e4tzlich beschreibt die Spezifikation die verf\u00fcgbaren Optionen, die die zur\u00fcckgegebenen Informationen beeinflussen. Wie eine Legacy-Spezifikation erfahren Sie \u00fcber ein System, seine Komponenten und seine Wechselwirkungen.<\/p>\r\n Ein weiterer Unterschied zwischen alten Spezifikationen und API-Spezifikationen besteht darin, dass API-Spezifikationen dynamisch sind. Wann auch immer sich der zugrunde liegende Quellcode einer API \u00e4ndert, aktualisiert sich die Dokumentation. Legacy-Spezifikationsdokumente erfordern eine manuelle Aktualisierung der Word-Dokumente, wenn sich das System \u00e4ndert.<\/p>\r\n Bevor Sie die Struktur einer OpenAPI-Spezifikation verstehen, m\u00fcssen Sie das Format eines OpenAPI-Dokuments verstehen. Anders als in Word geschriebene, alte Spezifikationen ist OpenAPIs Format JSON. W\u00e4hrend eine Diskussion der Nuancen von JSON f\u00fcr diesen Blog-Beitrag au\u00dfer Bereich ist, k\u00f6nnten Sie JSON als eine M\u00f6glichkeit betrachten, die Daten einer API als Schl\u00fcssel-Wert-Paare zu repr\u00e4sentieren.<\/span><\/p>\r\n Zum Beispiel in \u00e4lteren Spezifikationen schreiben Sie den Titel einer Spezifikation (einschlie\u00dflich des Namens des Systems) unter Verwendung eines Titelstils auf der Titelseite. Um den Titel einer Open API-Spezifikation zu schreiben, schreiben Sie den Titel als JSON-Schl\u00fcsselpaar.<\/span><\/p>\r\n Denken Sie nun an alle Informationen \u00fcber eine API. Seine Methoden, Operationen, Antworten, etc. Stellen Sie sich diese Eigenschaften vor, die in einer Reihe dieser Schl\u00fcssel-Wert-Paare dokumentiert sind, die der OpenAPI-Struktur folgen.<\/span><\/p>\r\n Hinweis:<\/b> W\u00e4hrend JSON das Standardformat f\u00fcr OpenAPI ist, ist es m\u00f6glich, OpenAPI in einfacherem YAML darzustellen (ein Abk\u00fcrzungszeichen, das f\u00fcr YAML ist keine Markup-Sprache).<\/span><\/p>\r\n Als JSON-Objekt unterst\u00fctzt die OpenAPI-Spezifikation Datentypen, die in der breiteren JSON-schematischen Spezifikation definiert sind. Primitive beinhalten Integer, Zahlen, Booleans und Zeichenketten. Sie k\u00f6nnen das Format eines Datentyps mit dem Modifikator-Eigenschaft Format angeben. Zum Beispiel k\u00f6nnen Sie eine Ganzzahl als int32 oder int64 Format angeben, eine Zahl als float oder double, oder eine Zeichenkette als Bin\u00e4r-, Daten-, Datums- oder Kennwortformat. OpenAPI unterst\u00fctzt auch Modelle (Objekte), die in der breiteren JSON-Spezifikation als Schema-Objekte definiert sind.<\/span><\/p>\r\n Es ist wichtig zu beachten, dass JSON das prim\u00e4re Format REST-APIs ist, die zum Senden und Empfangen von Informationen verwendet werden.<\/span><\/p>\r\n Bisher verstehen wir, dass:<\/span><\/p>\r\n Jetzt ist es an der Zeit, \u00fcber die Struktur von OpenAPI zu diskutieren.<\/span><\/p>\r\n Wie bereits erw\u00e4hnt, ist ein OpenAPI-Dokument streng strukturiert. Objekte oder Arrays von Objekten gruppieren bezogene Schl\u00fcssel-Wert-Paare. Die hochstufigen Objekte einer OpenAPI-Spezifikation sind wie die Kapitel eines alten Spezifikationsdokuments.<\/span><\/p>\r\n Unten ist ein <\/span>OpenAPI Vorlage<\/b> mit eingeklappten Abschnitten, um die Gesamtstruktur anzuzeigen. Jeder Abschnitt hat Eigenschaften, oder Schl\u00fcssel-Wert-Paare, die Metadaten \u00fcber die API liefern.<\/span><\/p>\r\n Die obere Ebene von OpenAPI, angegeben durch die ersten Klammern { }, wird als \u201eDokument Objekt\u201c bezeichnet, da es alle OpenAPI Eigenschaften enth\u00e4lt.<\/span><\/p>\r\n W\u00e4hrend OpenAPI Dokumente einer grundlegenden Struktur entsprechen m\u00fcssen, bietet OpenAPI eine gewisse Flexibilit\u00e4t. Einige der High-Level-Abschnitte sind erforderlich, andere nicht. Sie werden OpenAPI-Spezifikationen f\u00fcr verschiedene APIs bemerken, die etwas anders aussehen.<\/span><\/p>\r\n Ein OpenAPI-Dokument kann die folgenden Abschnitte enthalten:<\/span><\/p>\r\n Am Ende Ihrer API-Dokumentation, gibt es typischerweise einen Schema-Abschnitt, der den Schemas entspricht, die im Komponentenabschnitt der API-Definition beschrieben sind.<\/span><\/p>\r\n Dieser Abschnitt ist ein schnelles Glossar, wenn der Leser allgemeine Schemas im breiteren Kontext der API anzeigen muss (nicht deren Verwendung in bestimmten Operationen). Schemas sind Objekte, die Eigenschaften\/Metadaten enthalten.<\/span><\/p>\r\n Der folgende Schema-Abschnitt f\u00fcr den Swagger Petstore zeigt Spektralschemas an. <\/span>Order<\/b> ist ein Schema, das eine Bestellung f\u00fcr ein Haustier im Swagger Petstore darstellt. Jede Bestellung hat ihre Metadaten inklusive ID, das Datum der Versendung und den Status der Bestellung.<\/span><\/p>\r\n OpenAPI hat folgende Vorteile:<\/span><\/p>\r\n Jeder Spezifikationstyp hat seine St\u00e4rken und Schw\u00e4chen. Hier werden wir uns auf die Nachteile von OpenAPI im Vergleich zu seinem n\u00e4chsten Konkurrenten RAML konzentrieren.<\/span><\/p>\r\n Sie k\u00f6nnen einen \u201espec-first\u201c-Ansatz w\u00e4hlen, um eine API basierend auf OpenAPI zu entwerfen. Dieser Ansatz beinhaltet das Schreiben der OpenAPI-Spezifikation f\u00fcr eine API \u201evon Hand\u201c oder die Verwendung eines Designwerkzeugs. Mit diesem Ansatz entwerfen Sie eine API-Spezifikation und nutzen dann die Spezifikation als \u201eVertrag\u201c beim Bau der API. Das Gegenteil von \u201espec-first\u201c ist die Verwendung von OpenAPI zur Erstellung von Dokumentationen, ohne es als Design-Werkzeug zu verwenden.<\/span><\/p>\r\n Obwohl der \u201espec-first\u201c-Ansatz viele Vorteile hat, kommt OpenAPI normalerweise nicht vor der API-Entwicklung.<\/span><\/p>\r\n Die hierarchische Struktur von RAML kann sich als Planungs- und Konstruktionswerkzeug vermehren. Daher kann RAML den \u201espec-first\u201c-Ansatz mehr unterst\u00fctzen als REST. Letztendlich wird RAML als \u201eDatenmodellierung\u201c und API \u201eBeschreibung\u201c vermarktet, w\u00e4hrend Swagger das Letztere ist. Auf das hierarchische Modell von RAML wird im n\u00e4chsten Abschnitt n\u00e4her eingegangen.<\/span><\/p>\r\n Eines der Kernkonzepte f\u00fcr API-Definitionsstandards wie OpenAPI und RAML ist die F\u00e4higkeit, Datenobjekte zu erstellen und miteinander zu verbinden. OpenAPI verwendet hierf\u00fcr Schemas und unterst\u00fctzt JSON eingebaute Datentypen. RAML verwendet ein Typsystem, um assoziierte Eigenschaften zu speichern und die Wiederverwendung \u00fcber die gesamte Bandbreite hinweg zu f\u00f6rdern. Es unterst\u00fctzt auch die gleichen eingebauten Datentypen wie OpenAPI.<\/span><\/p>\r\n OpenAPI hat keine \u201eechte\u201c hierarchische Struktur. Was m\u00f6chten Sie aus einer hierarchischen Struktur, die Ihre API beschreibt? Idealerweise wollen Sie ein System zur Verkn\u00fcpfung Ihrer Datenmodelle, das:<\/span><\/p>\r\n Das RAML-Typsystem ist als System noch hierarchischer als REST. Laut RAMLs Readme auf GitHub minimiert der Einsatz von \u201eRessourcentypen und Merkmalen\u201c von RAML die Wiederholung in einem RESTful API-Design und f\u00f6rdert die Konsistenz innerhalb und \u00fcber APIs. Als n\u00e4chstes werden wir uns mit dem RAML-Typsystem detaillierter besch\u00e4ftigen.<\/span><\/p>\r\n Die Objekttypen von RAML k\u00f6nnen andere Objekttypen vererben. Obwohl OpenAPI Schemas \u201ereferenzieren\u201c k\u00f6nnen, unterst\u00fctzt es technisch keine Vererbung wie RAML. Ich sage \u201etechnisch\u201c, weil Sie ein Schema mit einem anderen verkn\u00fcpfen k\u00f6nnen, indem Sie eine Schema-Referenz verwenden ( $ref Tag). RAML geht jedoch noch einen Schritt weiter. Sie k\u00f6nnen Beziehungen zwischen Datenmodellen aufbauen und die Wiederholung gemeinsamer Eigenschaften vermeiden. Bei OpenAPI sind Schemas nicht hierarchisch wie RAML miteinander verkn\u00fcpft. RAML-Typen haben eine \u201eechte\u201c Vererbung und k\u00f6nnen Eltern-Kind-Beziehungen zwischen Datenmodellen aufbauen.<\/span><\/p>\r\n Der Einsatz von RAML als Datenmodell macht ihn visueller und leichter lesbar als OpenAPI. Sie k\u00f6nnen leicht die Beziehung zwischen den Typen und ihren gemeinsamen Eigenschaften sehen.<\/span><\/p>\r\n RAML als visuelleres Werkzeug f\u00f6rdert die langfristige Planung von Dingen wie Mock-Server-Antworten, API-Konsolen und mehr. Es k\u00f6nnte auch bei der Antizipierung und Planung von zuk\u00fcnftigen API-Verbesserungen mit RAML hilfreich sein.<\/span><\/p>\r\n Nur OpenAPI kann RESTful APIs beschreiben. RAML hat den zus\u00e4tzlichen Vorteil, andere Architekturen au\u00dfer REST zu unterst\u00fctzen wie RPC oder SOAP, solange sie das HTTP-Protokoll verwenden. Die Flexibilit\u00e4t von RAML erlaubt es Ihnen, es als Dokumentationswerkzeug f\u00fcr Architekturen neben REST zu verwenden.<\/span><\/p>\r\n Die beste Methode, OpenAPI zu lernen ist ein praktischer Ansatz. Bestimmte Tools erlauben es Ihnen, OpenAPI-Spezifikationen zu bearbeiten und dann API-Dokumentation zu generieren. Die Swagger Petstore Spezifikation ist ein Beispiel f\u00fcr ein OpenAPI Dokument.<\/span><\/p>\r\n SwaggerUI ist ein Tool, das eine API-Definition analysiert, um Dokumentation zu generieren. SwaggerUI hat einen browserbasierten Editor (unten angezeigt). Sie k\u00f6nnen mit dem SwaggerUI-Editor<\/a> experimentieren<\/span><\/p>\r\n Auf der linken Seite ist die OpenAPI-Spezifikation im YAML-Format sichtbar. Wenn Sie \u00c4nderungen an der Spezifikation vornehmen, erzeugen diese \u00c4nderungen neue Dokumentation im rechten Fenster. Das rechte Panel ist das Swagger-Dokument, das direkt aus der OpenAPI-Spezifikation f\u00fcr das Petstore (Panel auf der linken Seites) generiert wird. Zum Beispiel f\u00fchrt das \u00c4ndern der Beschreibung eines Pfades dazu, dass das Swagger-Dokument mit den neuen \u00c4nderungen aktualisiert wird.<\/span><\/p>\r\n Wenn Sie Swaggers OpenAPI spec auf der linken Seite betrachten, sehen Sie alle Sektionen, die in diesem Blog-Artikel beschrieben sind, einschlie\u00dflich <\/span>openapi, info, servers, paths, components, tags<\/b>, etc.<\/span><\/p>\r\n Swagger erzeugt eine Fehlermeldung, wenn Sie von der OpenAPI-Struktur abweichen oder etwas Ung\u00fcltiges eingeben. Die Fehlerbehandlung von Swagger betont den Ansatz, dass Sie das OpenAPI-Format beachten m\u00fcssen, damit die Dokumentation korrekt angezeigt wird. Sobald Sie sich mit dem Swagger Petstore vertraut gemacht haben, k\u00f6nnen Sie die Spezifikation f\u00fcr eine andere API in den Swagger-Editor einf\u00fcgen, um zu sehen, wie seine Informationen in SwaggerUI angezeigt werden.<\/span><\/p>\r\n Zusammenfassend ist Swagger Editor eine gro\u00dfartige M\u00f6glichkeit, sich mit dem Schreiben von API-Definitionen vertraut zu machen und wie Werkzeuge die Spezifikation analysieren, um Dokumentation zu generieren.<\/span><\/p>\r\n F\u00fcr eine ausf\u00fchrlichere Dokumentation zum OpenAPI-Standard lesen Sie die offizielle SmartBear-Dokumentation f\u00fcr OpenAPI: https:\/\/swagger.io\/specification\/.<\/p>\r\n Sind Sie bereit, Ihre API-Dokumentation auf das n\u00e4chste Level zu bringen? Buchen Sie noch heute eine Demo mit Document360!<\/span><\/p>\r\nDemo buchen<\/a><\/div>\r\n Eine offene API (auch als \u00f6ffentliche API bekannt) ist eine \u00f6ffentlich verf\u00fcgbare Programmierschnittstelle, die Entwicklern den Zugriff auf eine propriet\u00e4re Softwareanwendung oder einen Online-Dienst erm\u00f6glicht.<\/p>\r\n<\/div>\r\n<\/li>\r\n\t Eine offene API hat Zugriffsbeschr\u00e4nkungen, da sie \u00f6ffentlich zug\u00e4nglich ist und von \u00fcberall im offenen Netz aufgerufen werden kann. Eine geschlossene API, auch als private API bekannt, ist andererseits im Internet nicht \u00f6ffentlich zug\u00e4nglich.<\/p>\r\n<\/div>\r\n<\/li>\r\n\t Der OpenAPI Standard (OAS), fr\u00fcher als die Swagger Spezifikation bekannt, ist ein Format zur Beschreibung, Herstellung, Konsumierung und Visualisierung von RESTful Web-Diensten. Der REST API Standard beschreibt die Struktur und Syntax.<\/p>\r\n<\/div>\r\n<\/li>\r\n<\/ul>\r\n<\/div>\r\n<\/div>\r\n<\/div>\r\n\r\n\t
\r\n\t
\r\n\t
\r\n\t
Geschichte von OpenAPI<\/strong><\/h2>\r\n
Warum ist OpenAPI ein beliebter Standard?<\/strong><\/h2>\r\n
Wie definiert OpenAPI eine API?<\/strong><\/h2>\r\n
OpenAPI Format<\/h2>\r\n
![\"Titel](\"https:\/\/document360.com\/wp-content\/uploads\/2022\/12\/title_of_specification.png\")
<\/p>\r\nDatentypen<\/b><\/h2>\r\n
Struktur<\/b><\/h2>\r\n
\r\n\t
![\"API-Vorlage](\"https:\/\/document360.com\/wp-content\/uploads\/2022\/12\/API_template_with_structure.png\")
<\/p>\r\n\r\n\t
Schemas<\/h2>\r\n
![\"spec](\"https:\/\/document360.com\/wp-content\/uploads\/2022\/12\/spec_wide_schemas.png\")
<\/p>\r\nSt\u00e4rken von OpenAPI\u00a0<\/b><\/h2>\r\n
\r\n\t
Schw\u00e4chen von OpenAPI\u00a0<\/b><\/h2>\r\n
Weniger n\u00fctzlich f\u00fcr API-Design und Planung<\/b><\/h3>\r\n
Nicht Hierarchisch<\/b><\/h3>\r\n
\r\n\t
Unterst\u00fctzt keine Vererbung von Datenmodellen<\/b><\/h2>\r\n
Kein \u201evisuelles\u201c Werkzeug<\/b><\/h3>\r\n
Fehlende Unterst\u00fctzung f\u00fcr andere Architekturen<\/b><\/h3>\r\n
Beispiel von OpenAPI – Swagger Petstore<\/b><\/h2>\r\n
![\"Swagger](\"https:\/\/document360.com\/wp-content\/uploads\/2022\/12\/Swagger_UI_examples.png\")
<\/p>\r\nWeiterlesen<\/h2>\r\n
![\"Dokument360\"](\"https:\/\/document360.com\/wp-content\/themes\/document360\/images\/blog-call-to-action.png\")
<\/div>\r\n<\/div>\r\nH\u00e4ufig gestellte Fragen<\/h2>\r\n
\r\n\t
Was ist eine OpenAPI? <\/a><\/h3>\r\n
Was ist der Unterschied zwischen privaten und Open APIs? <\/a><\/h3>\r\n
Was ist OpenAPI und REST API?<\/a><\/h3>\r\n