{"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\/da\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway","title":{"rendered":"Vores erfaring med at skabe API Gateway","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Nogle virksomheder, herunder vores kunde, udvikler produktet gennem et partnernetv\u00e6rk. For eksempel er store online butikker integreret med en leveringsservice - du bestiller en vare og modtager snart et trackingnummer p\u00e5 pakken. Et andet eksempel er, n\u00e5r du k\u00f8ber en flybillet, k\u00f8ber du forsikring eller en billet til ekspresflybussen.<\/p>\n<p>Dette kr\u00e6ver \u00e9n API, som skal udleveres til partnerne gennem API Gateway. Denne opgave har vi l\u00f8st. I denne artikel vil vi dele detaljerne.<\/p>\n<p>Givet: et \u00f8kosystem og en API-portal med et interface, hvor brugerne er registreret, modtager information osv. Vi skal lave en brugervenlig og p\u00e5lidelig API Gateway. I processen skulle vi sikre <\/p>\n<ul>\n<li>registrering, <\/li>\n<li>kontrol af tilslutning til API, <\/li>\n<li>overv\u00e5gning af, hvordan brugere anvender det endelige system, <\/li>\n<li>opg\u00f8relse over forretningsparametre.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Vores erfaring med at skabe API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/4fa66fd4573af16b0bc78aa61173f907.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI artiklen vil vi fort\u00e6lle om vores erfaring med at skabe API Gateway, hvor vi har l\u00f8st f\u00f8lgende opgaver:<\/p>\n<ul>\n<li>autentificering af bruger,<\/li>\n<li>autorisation af bruger,<\/li>\n<li>modifikation af den oprindelige foresp\u00f8rgsel,<\/li>\n<li>proxyering af foresp\u00f8rgsel,<\/li>\n<li>efterbehandling af svaret.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nDer er to former for API-management:<\/p>\n<p>1. Standard, der fungerer p\u00e5 f\u00f8lgende m\u00e5de: F\u00f8r tilslutning tester brugeren mulighederne, derefter betaler de og integrerer p\u00e5 deres hjemmeside. Det anvendes oftest i sm\u00e5 og mellemstore virksomheder.<\/p>\n<p>2. Stor B2B API Management, hvor virksomheden f\u00f8rst tr\u00e6ffer en forretningsbeslutning om tilslutning, bliver partner med virksomheden med kontraktforpligtelser og tilslutter sig derefter API'en. Og f\u00f8rst efter at have f\u00e5et alle formaliteterne p\u00e5 plads, f\u00e5r virksomheden testadgang, gennemg\u00e5r testning og g\u00e5r i produktion. Men dette er umuligt uden en ledelsesm\u00e6ssig beslutning om tilslutning. <\/p>\n<p><img decoding=\"async\" alt=\"Vores erfaring med at skabe API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/b9ab53d6c64d5a971c4950cd340ad42e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3> Vores l\u00f8sning<\/h3>\n<p>\nI denne del vil vi fort\u00e6lle om oprettelsen af API Gateway.<\/p>\n<p>De endelige brugere af den oprettede API Gateway er partnere til vores kunde. For hver af dem har vi allerede de n\u00f8dvendige kontrakter gemt. Vi skal blot udvide funktionaliteten ved at angive den tildelte adgang til gatewayen. Derfor er der behov for en kontrolleret proces til tilslutning og styring.<\/p>\n<p>Selvf\u00f8lgelig kunne man have valgt en f\u00e6rdig l\u00f8sning til at l\u00f8se opgaven med API Management og oprettelse af API Gateway specifikt. For eksempel kunne det v\u00e6re<noindex><a rel=\"nofollow\" href=\"https:\/\/docs.microsoft.com\/en-us\/azure\/api-management\/\"> Azure API Management<\/a><\/noindex>Det passede os ikke, fordi vi allerede havde en API-portal og et stort \u00f8kosystem bygget omkring den. Alle brugere var allerede registreret, og de forstod allerede, hvor og hvordan de kunne f\u00e5 de n\u00f8dvendige oplysninger. De n\u00f8dvendige gr\u00e6nseflader var allerede til stede i API-portalen, vi havde kun brug for API Gateway. Det var faktisk udviklingen af den, vi gik i gang med. <\/p>\n<p>Det, vi kalder API Gateway, er en slags proxy. Her havde vi igen et valg \u2014 vi kunne enten skrive vores egen proxy, eller v\u00e6lge noget, der allerede var klar. I dette tilf\u00e6lde valgte vi den anden vej og valgte en kombination af nginx+Lua. Hvorfor? Vi havde brug for p\u00e5lidelig, testet software, der underst\u00f8ttede skalerbarhed. Vi \u00f8nskede ikke at skulle kontrollere b\u00e5de forretningslogikkens korrekthed og proxyens funktionalitet efter implementeringen. <\/p>\n<p>Enhver webserver har en procespipeline til h\u00e5ndtering af anmodninger. I tilf\u00e6lde af nginx ser den s\u00e5dan ud:<\/p>\n<p><img decoding=\"async\" alt=\"Vores erfaring med at skabe API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/b4cba1d37cc769202f92df052b45c77e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n(diagram fra <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openresty\/lua-nginx-module\">GitHub Lua Nginx<\/a><\/noindex>)<\/p>\n<p>Vores m\u00e5l var at integrere os i denne pipeline p\u00e5 det tidspunkt, hvor vi kunne modificere den oprindelige anmodning. <\/p>\n<p>Vi \u00f8nsker at skabe en transparent proxy, s\u00e5 anmodningen funktionelt forbliver, som den kom. Vi kontrollerer blot adgangen til den endelige API og hj\u00e6lper anmodningen med at n\u00e5 frem til den. Hvis anmodningen var forkert, skal den endelige API vise fejlen, men ikke vi. Den eneste grund til, at vi kan afvise anmodningen, er manglende adgang for klienten. <\/p>\n<p>Der findes allerede <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/openresty\/lua-nginx-module\">udvidelse<\/a><\/noindex> og f\u00e5 en fungerende kommando. <noindex><a rel=\"nofollow\" href=\"http:\/\/www.lua.ru\/\">Lua<\/a><\/noindex>. Lua er et scriptsprog, som er meget letv\u00e6gtigt og nemt at l\u00e6re. P\u00e5 den m\u00e5de gennemf\u00f8rte vi den n\u00f8dvendige logik med hj\u00e6lp fra Lua. <\/p>\n<p>Konfigurationen af nginx (analogi til ruten i applikationen), hvor alt arbejdet udf\u00f8res, er ganske forst\u00e5elig. Bem\u00e6rk her den sidste direktiv \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>\nLad os se p\u00e5, hvad der sker i denne konfiguration: <br \/>\n<b>more_clear_input_headers<\/b> \u2014 renser v\u00e6rdien af de angivne headere efter direktivet. <br \/>\n<b>lua_need_request_body <\/b>\u2014 regulerer, om det er n\u00f8dvendigt at l\u00e6se den oprindelige anmodningslegeme, f\u00f8r der udf\u00f8res direktiverne rewrite\/access\/access_by_lua. Som standard l\u00e6ser nginx ikke legemet af klientanmodningen, og hvis du har brug for at f\u00e5 adgang til det, skal denne direktiv have v\u00e6rdien on.<br \/>\n<b>rewrite_by_lua_file<\/b> \u2014 sti til scripts, som beskriver logikken for modificering af anmodningen<br \/>\n<b>access_by_lua_file <\/b>\u2014 sti til scriptet, som beskriver logikken for at kontrollere adgangen til ressourcen. <br \/>\n<b>proxy_pass <\/b>\u2014 url, hvortil anmodningen vil blive proxied.<br \/>\n<b>body_filter_by_lua_file <\/b>\u2014 sti til scriptet, som beskriver logikken for at filtrere anmodningen, inden den returneres til klienten.<br \/>\nOg til sidst, <b>post_action<\/b> \u2014 en officielt uofficiel direktiv, som g\u00f8r det muligt at udf\u00f8re yderligere handlinger efter at svaret er givet til klienten. <\/p>\n<p>Vi vil nu fort\u00e6lle i r\u00e6kkef\u00f8lge, hvordan vi l\u00f8ste vores opgaver.<\/p>\n<h3>Autorisation\/authentifikation og modificering af anmodningen<\/h3>\n<p>\n<b>Godkendelse<\/b><\/p>\n<p>Vi har etableret autorisation og autentifikation ved hj\u00e6lp af adgang baseret p\u00e5 certifikat. Der er et rodcertifikat. Hver ny kunde til bestilleren f\u00e5r genereret sit eget personlige certifikat, som giver adgang til API'et. Dette certifikat konfigureres i serversektionen af nginx-indstillingerne.<\/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>Modificering<\/b><\/p>\n<p>Der kan opst\u00e5 et legitimt sp\u00f8rgsm\u00e5l: hvad skal man g\u00f8re med en certificeret klient, hvis vi pludselig \u00f8nsker at frakoble ham fra systemet? Det ville ikke v\u00e6re rimeligt at genudstede certifikater til alle andre kunder. <\/p>\n<p>S\u00e5 vi har bl\u00f8dt landet til den n\u00e6ste opgave \u2014 modificering af den oprindelige anmodning. Den oprindelige anmodning fra klienten er generelt ikke gyldig for det endelige system. En af opgaverne er at tilf\u00f8je de manglende elementer i anmodningen for at g\u00f8re den gyldig. Det s\u00e6rlige er, at de manglende data varierer for hver klient. Vi ved, at klienten henvender sig til os med et certifikat, hvorfra vi kan tage et fingeraftryk og tr\u00e6kke de n\u00f8dvendige data fra databasen. <\/p>\n<p>Hvis der p\u00e5 et tidspunkt bliver behov for at frakoble klienten fra vores service, vil hans data forsvinde fra databasen, og han vil ikke kunne g\u00f8re noget. <\/p>\n<h3>Arbejde med klientdata<\/h3>\n<p>\nVi havde brug for at sikre h\u00f8j tilg\u00e6ngelighed af l\u00f8sningen, is\u00e6r n\u00e5r det g\u00e6lder, hvordan vi f\u00e5r klientdata. Problemet er, at kilden til disse data er en tredjepartstjeneste, som ikke garanterer uafbrudt og tilstr\u00e6kkelig h\u00f8j hastighed. <\/p>\n<p>Derfor var vi n\u00f8dt til at sikre h\u00f8j tilg\u00e6ngelighed af klientdata. Som v\u00e6rkt\u00f8j valgte vi <noindex><a rel=\"nofollow\" href=\"https:\/\/hazelcast.org\/\">Hazelcast<\/a><\/noindex>, som giver os:<\/p>\n<ul>\n<li>hurtig adgang til data,<\/li>\n<li>muligheden for at organisere et cluster af flere noder med replikerede data p\u00e5 forskellige noder.<\/li>\n<\/ul>\n<p>\nVi valgte den enkleste strategi til at levere data til cachen:<\/p>\n<p><img decoding=\"async\" alt=\"Vores erfaring med at skabe API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/0175d6f0fda543566ab13d4cae9d8cc1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nArbejdet med det endelige system foreg\u00e5r i sessioner, og der er en gr\u00e6nse for det maksimale antal. Hvis kunden ikke lukker sessionen, m\u00e5 vi g\u00f8re det. <\/p>\n<p>Data om den \u00e5bne session kommer fra det endelige system og bliver oprindeligt behandlet p\u00e5 Lua-siden. Vi besluttede at bruge Hazelcast til at gemme disse data med en job, der er skrevet i .NET. Derefter tjekker vi med j\u00e6vne mellemrum retten til at forblive \u00e5bne sessioner og lukker de udl\u00f8bne. <\/p>\n<h3>Adgang til Hazelcast b\u00e5de fra Lua og fra .NET<\/h3>\n<p>\nDer findes ikke klienter til Lua for at arbejde med Hazelcast, men Hazelcast har et REST API, som vi valgte at benytte. For .NET er der <noindex><a rel=\"nofollow\" href=\"https:\/\/hazelcast.org\/clients\/net\/\">client<\/a><\/noindex>, som vi planlagde at f\u00e5 adgang til data fra Hazelcast p\u00e5 .NET-siden. Men ikke s\u00e5 hurtigt.<\/p>\n<p><img decoding=\"async\" alt=\"Vores erfaring med at skabe API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/52c9437e5cd16073b56afc55a4f415da.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nN\u00e5r data gemmes via REST og hentes gennem .NET-klienten, bruges forskellige serialisatorer deserialisatorer. Derfor er det umuligt at lagre data via REST og hente dem gennem .NET-klienten og omvendt. <\/p>\n<p>Hvis der er interesserede, vil vi fort\u00e6lle mere om dette problem i en separat artikel. Spoiler - p\u00e5 diagrammet. <\/p>\n<p><img decoding=\"async\" alt=\"Vores erfaring med at skabe API Gateway\" src=\"\/wp-content\/uploads\/2019\/04\/73bb11214fdaeca86ef10cdbd788e288.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Logging og overv\u00e5gning<\/h3>\n<p>\nVores virksomhedstandard for logging gennem .NET er Serilog, alle logs havner til sidst i Elasticsearch, og vi analyserer dem via Kibana. Vi \u00f8nskede at g\u00f8re noget lignende i dette tilf\u00e6lde. Den eneste <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/DhavalKapil\/elasticsearch-lua\">client<\/a><\/noindex> til at arbejde med Elastic p\u00e5 Lua, der blev fundet, br\u00f8d sammen p\u00e5 den f\u00f8rste require. Og vi brugte Fluentd. <\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.fluentd.org\/\">Fluentd<\/a><\/noindex> \u2014 en open source-l\u00f8sning til at levere et enhedslag af applikationslogging. Giver mulighed for at samle logs fra forskellige lag af applikationen og derefter sende dem til en samlet kilde. <\/p>\n<p>API Gateway k\u00f8rer i K8S, s\u00e5 vi besluttede at tilf\u00f8je en container med fluentd til den samme pod for at skrive logs til den eksisterende \u00e5bne TCP-port fluentd. <\/p>\n<p>Vi unders\u00f8gte ogs\u00e5, hvordan fluentd ville fungere, hvis den ikke havde forbindelse til Elasticsearch. I to dage modtog gatewayen kontinuerligt foresp\u00f8rgsler, logs blev sendt til fluentd, men IP-adressen til Elastic blev blokeret for fluentd. Efter genoprettelsen af forbindelsen sendte fluentd alle logs perfekt til Elastic.<\/p>\n<h3>Konklusion<\/h3>\n<p>\nDen valgte tilgang til implementering gjorde det muligt for os at levere et reelt fungerende produkt til driftsmilj\u00f8et p\u00e5 blot 2,5 m\u00e5neder.<\/p>\n<p>Hvis du nogensinde skulle besk\u00e6ftige dig med lignende opgaver, anbefaler vi f\u00f8rst at forst\u00e5 klart, hvilken opgave du l\u00f8ser, og hvilke ressourcer du allerede har. V\u00e6r opm\u00e6rksom p\u00e5 udfordringerne ved integration med eksisterende API-styringssystemer. <\/p>\n<p>Forst\u00e5 for dig selv, hvad pr\u00e6cist du har t\u00e6nkt dig at udvikle - kun forretningslogikken til behandling af anmodninger eller, som det kunne v\u00e6re i vores tilf\u00e6lde, en fuld proxy. Glem ikke, at alt det, du laver selv, skal testes grundigt senere.<br \/>\n<br \/>Kilde: <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.3 - 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\/da\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\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\/da\/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\udd47Vores erfaring med at skabe API Gateway | ProHoster","description":"Nogle virksomheder, herunder vores kunde, udvikler produktet gennem et partnernetv\u00e6rk.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/nash-opyt-sozdaniya-api-gateway","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/30792","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=30792"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/30792\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/22777"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=30792"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=30792"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=30792"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}