{"id":30792,"date":"2019-10-31T21:37:27","date_gmt":"2019-10-31T18:37:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/nash-opyt-sozdaniya-api-gateway\/"},"modified":"2019-10-31T21:37:27","modified_gmt":"2019-10-31T18:37:27","slug":"nash-opyt-sozdaniya-api-gateway","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway","title":{"rendered":"Unsere Erfahrung mit der Erstellung eines API Gateways","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Einige Unternehmen, darunter auch unser Kunde, entwickeln das Produkt \u00fcber ein Partnernetzwerk. Zum Beispiel sind gro\u00dfe Online-Shops mit einem Lieferdienst integriert \u2013 Sie bestellen einen Artikel und erhalten bald darauf eine Sendungsverfolgungsnummer. Ein weiteres Beispiel \u2013 zusammen mit dem Flugticket kaufen Sie eine Versicherung oder ein Ticket f\u00fcr den Flughafenexpress.<\/p>\n<p>Hierf\u00fcr wird eine API verwendet, die \u00fcber das API-Gateway an Partner ausgegeben werden muss. Diese Aufgabe haben wir gel\u00f6st. In diesem Artikel werden wir die Einzelheiten erl\u00e4utern.<\/p>\n<p>Gegeben: ein \u00d6kosystem und ein API-Portal mit einer Schnittstelle, in der die Benutzer registriert sind, Informationen erhalten usw. Wir m\u00fcssen ein benutzerfreundliches und zuverl\u00e4ssiges API-Gateway erstellen. Dabei mussten wir sicherstellen, <\/p>\n<ul>\n<li>die Registrierung, <\/li>\n<li>die Kontrolle des Zugriffs auf die API, <\/li>\n<li>die \u00dcberwachung, wie Benutzer das Endsystem nutzen, <\/li>\n<li>die Erfassung von Gesch\u00e4ftszahlen.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Unsere Erfahrung mit der Erstellung eines API Gateways\" src=\"\/wp-content\/uploads\/2019\/04\/4fa66fd4573af16b0bc78aa61173f907.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn diesem Artikel werden wir von unseren Erfahrungen bei der Erstellung eines API-Gateways berichten, w\u00e4hrend wir die folgenden Aufgaben gel\u00f6st haben:<\/p>\n<ul>\n<li>Benutzer-Authentifizierung,<\/li>\n<li>Benutzer-Autorisierung,<\/li>\n<li>Modifikation der urspr\u00fcnglichen Anfrage,<\/li>\n<li>Proxying der Anfrage,<\/li>\n<li>Nachbearbeitung der Antwort.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nEs gibt zwei Arten des API-Managements:<\/p>\n<p>1. Standard, der folgenderma\u00dfen funktioniert. Bevor der Benutzer sich verbindet, testet er die M\u00f6glichkeiten, zahlt dann und integriert es auf seiner Website. Dieser wird h\u00e4ufig im kleinen und mittleren Unternehmen genutzt.<\/p>\n<p>2. Gro\u00dfes B2B API-Management, bei dem das Unternehmen zun\u00e4chst eine gesch\u00e4ftliche Entscheidung \u00fcber die Verbindung trifft, Partner des Unternehmens mit vertraglichen Verpflichtungen wird, und sich dann mit der API verbindet. Erst nach Kl\u00e4rung aller Formalit\u00e4ten erh\u00e4lt das Unternehmen Testzugang, durchl\u00e4uft Tests und geht live. Doch dies ist ohne eine Managemententscheidung \u00fcber die Verbindung nicht m\u00f6glich. <\/p>\n<p><img decoding=\"async\" alt=\"Unsere Erfahrung mit der Erstellung eines API Gateways\" src=\"\/wp-content\/uploads\/2019\/04\/b9ab53d6c64d5a971c4950cd340ad42e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3> Unsere L\u00f6sung<\/h3>\n<p>\nIn diesem Abschnitt werden wir \u00fcber die Erstellung des API-Gateways berichten.<\/p>\n<p>Die Endbenutzer des erstellten API-Gateways sind die Partner unseres Kunden. F\u00fcr jeden von ihnen haben wir bereits die erforderlichen Vertr\u00e4ge gespeichert. Wir m\u00fcssen nur die Funktionalit\u00e4t erweitern, indem wir den bereitgestellten Zugang zum Gateway kennzeichnen. Dementsprechend ist ein kontrollierter Verbindungs- und Verwaltungsprozess erforderlich.<\/p>\n<p>Nat\u00fcrlich h\u00e4tten wir eine vorhandene L\u00f6sung f\u00fcr das API-Management und insbesondere f\u00fcr die Erstellung eines API-Gateways verwenden k\u00f6nnen. Ein Beispiel daf\u00fcr k\u00f6nnte sein<noindex><a rel=\"nofollow\" href=\"https:\/\/docs.microsoft.com\/en-us\/azure\/api-management\/\"> Azure API Management<\/a><\/noindex>. Es passte nicht zu uns, da wir bereits ein API-Portal und ein riesiges \u00d6kosystem darum herum hatten. Alle Benutzer waren bereits registriert und wussten, wo und wie sie die ben\u00f6tigten Informationen erhalten konnten. Im API-Portal gab es bereits die erforderlichen Schnittstellen, wir ben\u00f6tigten nur einen API Gateway. Tats\u00e4chlich haben wir uns mit dessen Entwicklung besch\u00e4ftigt. <\/p>\n<p>Was wir API Gateway nennen, ist eine Art Proxy. Hier hatten wir wieder eine Wahl \u2014 wir konnten unseren eigenen Proxy schreiben oder etwas Fertiges w\u00e4hlen. In diesem Fall haben wir den zweiten Weg gew\u00e4hlt und uns f\u00fcr die Kombination nginx+Lua entschieden. Warum? Wir ben\u00f6tigten zuverl\u00e4ssige, getestete Software, die Skalierung unterst\u00fctzt. Nach der Implementierung wollten wir nicht die Gesch\u00e4ftsanfragenvalidit\u00e4t und die Funktionsf\u00e4higkeit des Proxys \u00fcberpr\u00fcfen. <\/p>\n<p>Jeder Webserver hat eine Anfrageverarbeitungspipeline. Im Fall von nginx sieht sie wie folgt aus:<\/p>\n<p><img decoding=\"async\" alt=\"Unsere Erfahrung mit der Erstellung eines API Gateways\" src=\"\/wp-content\/uploads\/2019\/04\/b4cba1d37cc769202f92df052b45c77e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n(Diagramm aus <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openresty\/lua-nginx-module\">GitHub Lua Nginx<\/a><\/noindex>)<\/p>\n<p>Unser Ziel war es, uns in diese Pipeline an dem Punkt einzuf\u00fcgen, an dem wir die urspr\u00fcngliche Anfrage modifizieren k\u00f6nnen. <\/p>\n<p>Wir wollen einen transparenten Proxy erstellen, sodass die Funktionalit\u00e4t der Anfrage so bleibt, wie sie angekommen ist. Wir kontrollieren nur den Zugriff auf die endg\u00fcltige API und helfen der Anfrage, sie zu erreichen. Im Falle einer ung\u00fcltigen Anfrage sollte die endg\u00fcltige API den Fehler anzeigen, nicht wir. Der einzige Grund, aus dem wir eine Anfrage ablehnen k\u00f6nnen, ist der fehlende Zugang des Clients. <\/p>\n<p>F\u00fcr nginx gibt es bereits ein <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openresty\/lua-nginx-module\">Erweiterung<\/a><\/noindex> auf <noindex><a rel=\"nofollow\" href=\"http:\/\/www.lua.ru\/\">Lua<\/a><\/noindex>. Lua ist eine Skriptsprache, die sehr leichtgewichtig und einfach zu erlernen ist. Somit haben wir die notwendige Logik mit Lua umgesetzt. <\/p>\n<p>Die Konfiguration von nginx (analoge Route der Anwendung), wo die gesamte Arbeit verrichtet wird, ist ziemlich verst\u00e4ndlich. Bemerkenswert ist hier die letzte Direktive \u2014 post_action.<\/p>\n<pre><code class=\"nginx\">location \/middleware {\n      more_clear_input_headers Accept-Encoding;\n      lua_need_request_body on;\n      rewrite_by_lua_file 'middleware\/rewrite.lua';\n      access_by_lua_file 'middleware\/access.lua';\n      proxy_pass https:\/\/someurl.com;\n      body_filter_by_lua_file 'middleware\/body_filter.lua';\n      post_action \/process_session;\n}\n<\/code><\/pre>\n<p>\nLassen Sie uns betrachten, was in dieser Konfiguration geschieht: <br \/>\n<b>more_clear_input_headers<\/b> \u2014 entfernt den Wert der nach der Direktive angegebenen Header. <br \/>\n<b>lua_need_request_body <\/b>\u2014 regelt, ob der urspr\u00fcngliche Anfragek\u00f6rper gelesen werden soll, bevor die Direktiven rewrite\/access\/access_by_lua ausgef\u00fchrt werden. Standardm\u00e4\u00dfig liest nginx den Anfragek\u00f6rper des Clients nicht, und wenn Sie darauf zugreifen m\u00fcssen, muss diese Direktive den Wert on haben.<br \/>\n<b>rewrite_by_lua_file<\/b> \u2014 Pfad zum Skript, in dem die Logik zur Modifikation der Anfrage beschrieben ist<br \/>\n<b>access_by_lua_file <\/b>\u2014 Pfad zum Skript, in dem die Logik zur \u00dcberpr\u00fcfung des Zugriffs auf die Ressource beschrieben ist. <br \/>\n<b>proxy_pass <\/b>\u2014 URL, an die die Anfrage weitergeleitet wird.<br \/>\n<b>body_filter_by_lua_file <\/b>\u2014 Pfad zum Skript, in dem die Logik zur Filterung der Anfrage vor der R\u00fcckgabe an den Client beschrieben ist.<br \/>\nUnd schlie\u00dflich, <b>post_action<\/b> \u2014 offiziell nicht dokumentierte Direktive, mit der weitere Aktionen ausgef\u00fchrt werden k\u00f6nnen, nachdem die Antwort an den Client gegeben wurde. <\/p>\n<p>Im Folgenden erkl\u00e4ren wir der Reihe nach, wie wir unsere Aufgaben gel\u00f6st haben.<\/p>\n<h3>Autorisierung\/Authentifizierung und Modifikation der Anfrage<\/h3>\n<p>\n<b>Autorisierung<\/b><\/p>\n<p>Die Autorisierung und Authentifizierung haben wir mithilfe von Zug\u00e4ngen \u00fcber Zertifikate umgesetzt. Es gibt ein Root-Zertifikat. F\u00fcr jeden neuen Kunden des Auftraggebers wird ein pers\u00f6nliches Zertifikat generiert, mit dem er Zugang zur API erhalten kann. Dieses Zertifikat wird im Abschnitt server der Nginx-Einstellungen konfiguriert.<\/p>\n<pre><code class=\"nginx\">ssl on;\nssl_certificate \/usr\/local\/openresty\/nginx\/ssl\/cert.pem;\nssl_certificate_key \/usr\/local\/openresty\/nginx\/ssl\/cert.pem;\nssl_client_certificate \/usr\/local\/openresty\/nginx\/ssl\/ca.crt;\nssl_verify_client on;<\/code><\/pre>\n<p>\n<b>Modifikation<\/b><\/p>\n<p>Es k\u00f6nnte die berechtigte Frage aufkommen: Was tun wir mit einem zertifizierten Kunden, wenn wir ihn pl\u00f6tzlich vom System abmelden wollen? Sollen wir alle anderen Kunden zwingen, neue Zertifikate zu beantragen? <\/p>\n<p>So sind wir sanft zur n\u00e4chsten Aufgabe \u00fcbergegangen \u2014 der Modifikation der urspr\u00fcnglichen Anfrage. Die urspr\u00fcngliche Anfrage des Clients ist, gelinde gesagt, nicht g\u00fcltig f\u00fcr das Zielsystem. Eine der Aufgaben besteht darin, fehlende Teile in die Anfrage einzuf\u00fcgen, um sie g\u00fcltig zu machen. Der Clou ist, dass die fehlenden Daten f\u00fcr jeden Client unterschiedlich sind. Wir wissen, dass der Client mit einem Zertifikat zu uns kommt, von dem wir den Fingerabdruck nehmen und die erforderlichen Daten des Kunden aus der Datenbank abrufen k\u00f6nnen. <\/p>\n<p>Falls zu einem sp\u00e4teren Zeitpunkt der Bedarf besteht, den Kunden von unserem Service abzumelden, verschwinden seine Daten aus der Datenbank und er kann nichts mehr tun. <\/p>\n<h3>Arbeiten mit den Kundendaten<\/h3>\n<p>\nWir mussten eine hohe Verf\u00fcgbarkeit der L\u00f6sung sicherstellen, insbesondere daf\u00fcr, wie wir die Kundendaten abrufen. Die Schwierigkeit besteht darin, dass die Quelle dieser Daten ein externer Dienst ist, der keine durchg\u00e4ngige und ausreichend hohe Geschwindigkeit garantiert. <\/p>\n<p>Daher mussten wir eine hohe Verf\u00fcgbarkeit der Kundendaten sicherstellen. Als Werkzeug haben wir <noindex><a rel=\"nofollow\" href=\"https:\/\/hazelcast.org\/\">Hazelcast<\/a><\/noindex>, das uns Folgendes bietet:<\/p>\n<ul>\n<li>schneller Zugriff auf Daten,<\/li>\n<li>die M\u00f6glichkeit, einen Cluster aus mehreren Knoten mit replizierten Daten auf verschiedenen Knoten zu organisieren.<\/li>\n<\/ul>\n<p>\nWir haben die einfachste Strategie zur Daten\u00fcbertragung in den Cache gew\u00e4hlt:<\/p>\n<p><img decoding=\"async\" alt=\"Unsere Erfahrung mit der Erstellung eines API Gateways\" src=\"\/wp-content\/uploads\/2019\/04\/0175d6f0fda543566ab13d4cae9d8cc1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDie Arbeit mit dem Endsystem erfolgt im Rahmen von Sitzungen, und es gibt eine Begrenzung f\u00fcr die maximale Anzahl. Wenn der Kunde die Sitzung jedoch nicht geschlossen hat, m\u00fcssen wir dies tun. <\/p>\n<p>Die Daten zur offenen Sitzung kommen vom Endsystem und werden zun\u00e4chst auf der Lua-Seite verarbeitet. Wir haben uns entschieden, Hazelcast zu verwenden, um diese Daten mit einem Job, der in .NET geschrieben wurde, zu speichern. Dann \u00fcberpr\u00fcfen wir in bestimmten Abst\u00e4nden das Lebensrecht der offenen Sitzungen und schlie\u00dfen abgelaufene. <\/p>\n<h3>Zugriff auf Hazelcast sowohl aus Lua als auch aus .NET<\/h3>\n<p>\nEs gibt keine Lua-Clients f\u00fcr die Arbeit mit Hazelcast, aber Hazelcast hat eine REST-API, die wir nutzen wollten. F\u00fcr .NET gibt es jedoch <noindex><a rel=\"nofollow\" href=\"https:\/\/hazelcast.org\/clients\/net\/\">Client<\/a><\/noindex>, \u00fcber den wir planen, Zugang zu den Hazelcast-Daten auf der .NET-Seite zu erhalten. Doch es kam anders.<\/p>\n<p><img decoding=\"async\" alt=\"Unsere Erfahrung mit der Erstellung eines API Gateways\" src=\"\/wp-content\/uploads\/2019\/04\/52c9437e5cd16073b56afc55a4f415da.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBeim Speichern von Daten \u00fcber REST und Abrufen \u00fcber den .NET-Client werden unterschiedliche Serializer\/Deserializer verwendet. Daher ist es unm\u00f6glich, Daten \u00fcber REST zu speichern und \u00fcber den .NET-Client abzurufen und umgekehrt. <\/p>\n<p>Wenn es Interessierte gibt, werden wir in einem separaten Artikel n\u00e4her auf dieses Problem eingehen. Spoiler \u2014 im Diagramm. <\/p>\n<p><img decoding=\"async\" alt=\"Unsere Erfahrung mit der Erstellung eines API Gateways\" src=\"\/wp-content\/uploads\/2019\/04\/73bb11214fdaeca86ef10cdbd788e288.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Protokollierung und Monitoring<\/h3>\n<p>\nUnser Unternehmensstandard f\u00fcr Protokollierung \u00fcber .NET ist Serilog, alle Protokolle landen letztendlich in Elasticsearch, die Analyse erfolgt \u00fcber Kibana. Etwas \u00c4hnliches wollten wir auch in diesem Fall machen. Leider <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/DhavalKapil\/elasticsearch-lua\">Client<\/a><\/noindex> fand der einzige Client f\u00fcr die Arbeit mit Elastic auf Lua bei der ersten require-Anweisung nicht statt. Und wir haben Fluentd verwendet. <\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.fluentd.org\/\">Fluentd<\/a><\/noindex> ist eine Open-Source-L\u00f6sung zur Bereitstellung einer einheitlichen Protokollierungsschicht der Anwendung. Sie erm\u00f6glicht das Sammeln von Protokollen aus verschiedenen Schichten der Anwendung und deren \u00dcbertragung an eine einheitliche Quelle. <\/p>\n<p>API Gateway l\u00e4uft in K8S, daher haben wir entschieden, einen Container mit Fluentd in dasselbe Pod zu integrieren, um Protokolle in den vorhandenen offenen TCP-Port von Fluentd zu schreiben. <\/p>\n<p>Wir haben auch untersucht, wie sich Fluentd verh\u00e4lt, wenn es keine Verbindung zu Elasticsearch hat. \u00dcber zwei Tage lang gingen kontinuierlich Anfragen an das Gateway, Protokolle wurden an Fluentd gesendet, aber die IP von Elastic war f\u00fcr Fluentd gesperrt. Nach Wiederherstellung der Verbindung hat Fluentd alle Protokolle erfolgreich an Elastic \u00fcbertragen.<\/p>\n<h3>Fazit<\/h3>\n<p>\nDer gew\u00e4hlte Implementierungsansatz erm\u00f6glichte es uns, ein funktionierendes Produkt in einer Produktionsumgebung in nur 2,5 Monaten bereitzustellen.<\/p>\n<p>Wenn Sie jemals mit solchen Dingen zu tun haben, empfehlen wir Ihnen, zuerst genau zu verstehen, welche Aufgabe Sie l\u00f6sen und welche Ressourcen Ihnen bereits zur Verf\u00fcgung stehen. Achten Sie auf die Herausforderungen bei der Integration mit bestehenden API-Management-Systemen. <\/p>\n<p>Verstehen Sie f\u00fcr sich selbst, was genau Sie entwickeln m\u00f6chten \u2013 nur die Gesch\u00e4ftslogik zur Verarbeitung von Anfragen oder, wie es in unserem Fall der Fall sein k\u00f6nnte, das gesamte Proxy. Vergessen Sie nicht, dass alles, was Sie selbst tun, anschlie\u00dfend gr\u00fcndlich getestet werden muss.<br \/>\n<br \/>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/true_engineering\/blog\/446438\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u0432 \u0442\u043e\u043c \u0447\u0438\u0441\u043b\u0435 \u043d\u0430\u0448 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a, \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0434\u0443\u043a\u0442 \u0447\u0435\u0440\u0435\u0437 \u043f\u0430\u0440\u0442\u043d\u0435\u0440\u0441\u043a\u0443\u044e \u0441\u0435\u0442\u044c. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043a\u0440\u0443\u043f\u043d\u044b\u0435 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u043c\u0430\u0433\u0430\u0437\u0438\u043d\u044b \u0438\u043d\u0442\u0435\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u043d\u044b \u0441\u043e \u0441\u043b\u0443\u0436\u0431\u043e\u0439 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u2014 \u0432\u044b \u0437\u0430\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0435 \u0442\u043e\u0432\u0430\u0440 \u0438 \u0432\u0441\u043a\u043e\u0440\u0435 \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u0442\u0435 \u0442\u0440\u0435\u043a\u0438\u043d\u0433\u043e\u0432\u044b\u0439 \u043d\u043e\u043c\u0435\u0440 \u043f\u043e\u0441\u044b\u043b\u043a\u0438. \u0414\u0440\u0443\u0433\u043e\u0439 \u043f\u0440\u0438\u043c\u0435\u0440 \u2014 \u0432\u043c\u0435\u0441\u0442\u0435 \u0441 \u0430\u0432\u0438\u0430\u0431\u0438\u043b\u0435\u0442\u043e\u043c \u0432\u044b \u043f\u043e\u043a\u0443\u043f\u0430\u0435\u0442\u0435 \u0441\u0442\u0440\u0430\u0445\u043e\u0432\u043a\u0443 \u0438\u043b\u0438 \u0431\u0438\u043b\u0435\u0442 \u043d\u0430 \u0430\u044d\u0440\u043e\u044d\u043a\u0441\u043f\u0440\u0435\u0441\u0441. \u0414\u043b\u044f \u044d\u0442\u043e\u0433\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0441\u044f \u043e\u0434\u0438\u043d API, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u043d\u0443\u0436\u043d\u043e \u0432\u044b\u0434\u0430\u0442\u044c \u043f\u0430\u0440\u0442\u043d\u0435\u0440\u0430\u043c \u0447\u0435\u0440\u0435\u0437 API Gateway. \u042d\u0442\u0443 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":22777,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-30792","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u0432 \u0442\u043e\u043c \u0447\u0438\u0441\u043b\u0435 \u043d\u0430\u0448 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a, \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0434\u0443\u043a\u0442 \u0447\u0435\u0440\u0435\u0437 \u043f\u0430\u0440\u0442\u043d\u0435\u0440\u0441\u043a\u0443\u044e \u0441\u0435\u0442\u044c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041d\u0430\u0448 \u043e\u043f\u044b\u0442 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f API Gateway | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u0432 \u0442\u043e\u043c \u0447\u0438\u0441\u043b\u0435 \u043d\u0430\u0448 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a, \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0434\u0443\u043a\u0442 \u0447\u0435\u0440\u0435\u0437 \u043f\u0430\u0440\u0442\u043d\u0435\u0440\u0441\u043a\u0443\u044e \u0441\u0435\u0442\u044c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:37:27+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:37:27+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Unsere Erfahrung in der Erstellung von API-Gateways | ProHoster","description":"Einige Unternehmen, darunter unser Auftraggeber, entwickeln das Produkt \u00fcber ein Partnernetzwerk weiter.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041d\u0430\u0448 \u043e\u043f\u044b\u0442 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f API Gateway | ProHoster","og:description":"\u041d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u0432 \u0442\u043e\u043c \u0447\u0438\u0441\u043b\u0435 \u043d\u0430\u0448 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a, \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0434\u0443\u043a\u0442 \u0447\u0435\u0440\u0435\u0437 \u043f\u0430\u0440\u0442\u043d\u0435\u0440\u0441\u043a\u0443\u044e \u0441\u0435\u0442\u044c.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:37:27+00:00","article:modified_time":"2019-10-31T18:37:27+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"30792","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 03:01:22","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 17:05:31","updated":"2026-01-21 03:01:22","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/30792","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=30792"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/30792\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/22777"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=30792"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=30792"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=30792"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}