api工廠接口路徑是什么

by Vitaly Kondratiev

通過維塔利·康德拉季耶夫(Vitaly Kondratiev)

為什么(幾乎)永遠不要再使用絕對路徑訪問API (Why you should (almost) never use an absolute path to your APIs again)

Recent advances in web apps architecture show that a decoupled front-end provides more flexibility for development and operations. It

Web應用程序體系結構的最新進展表明，分離的前端為開發和操作提供了更大的靈活性。它

lets you work on one end without depending on the other
使您可以在一端工作而無需依賴另一端
lets you build and deploy separately
讓您分別構建和部署
makes it easy to use different tools on each end
易于在兩端使用不同的工具

問題 (The problem)

When an app is developed with this architecture in mind, the front-end needs to communicate to the back-end via APIs, generally REST. Often, the URL/port of the back-end server differs from the front-end’s one, given separate deployment paths. In this example, the URL to the front-end app is https://www.appfocused.com and the REST endpoint to send contact emails is served from https://api.appfocused.com.

當開發應用時要考慮這種架構，前端需要通過API(通常為REST)與后端進行通信。在給定單獨的部署路徑的情況下，后端服務器的URL /端口通常與前端服務器的URL /端口不同。在此示例中，前端應用程序的URL為https://www.appfocused.com ，用于發送聯系人電子郵件的REST終結點從https://api.appfocused.com 。

An HTTP request from the front-end app to the back-end server will fail as it violates the Same Origin Policy. In Chrome’s console it will look like this:

從前端應用程序到后端服務器的HTTP請求將失敗，因為它違反了Same Origin Policy 。在Chrome瀏覽器的控制臺中，它將如下所示：

Browsers, for security reasons, restrict requests which are not from the same origin. This prevents attackers from injecting code into our app and stealing our sensitive information. Browsers append an origin header on cross-origin requests to let the server know of a potential threat. The server then has the authority to either allow or reject these origins by providing specific response headers, which are parsed by the browsers.

出于安全原因，瀏覽器會限制來自不同來源的請求。這可以防止攻擊者將代碼注入我們的應用程序并竊取我們的敏感信息。瀏覽器在跨域請求上附加一個origin ，以使服務器知道潛在威脅。然后，服務器有權通過提供特定的響應頭來允許或拒絕這些來源，這些響應頭由瀏覽器解析。

There are two solutions to fix this small problem:

有兩種解決此小問題的方法：

hardcode absolute API URLs on the client and configure CORS headers on the server
在客戶端上硬編碼絕對API URL，并在服務器上配置CORS標頭
use relative API URLs on the client and use a reverse-proxy approach
在客戶端上使用相對的API URL并使用反向代理方法

In this post, I talk about why the former approach with CORS headers should be considered an anti-pattern for production-ready code. I also talk about how to configure the reverse-proxy approach on various setups:

在本文中，我討論了為什么以前的帶有CORS標頭的方法應被視為生產就緒代碼的反模式。我還討論了如何在各種設置上配置反向代理方法：

local devserver
本地開發服務器
web server / app server
網絡服務器/應用服務器
serverless (CloudFront / S3 / Lambda)
無服務器(CloudFront / S3 / Lambda)

基本原理 (Rationale)

The CORS headers scenario sounds like less pain to implement, and it is. However, there are a few concerns to consider that made me preach for the reverse proxy approach under almost any circumstances.

事實證明，CORS標頭方案的實現聽起來很輕松，而且確實如此。但是，在幾乎所有情況下，都有一些需要考慮的因素使我鼓吹反向代理方法 。

First and foremost, the back-end might not be owned by you and it might be impossible to make the change to the CORS headers.

首先，后端可能不屬于您，并且可能無法更改CORS標頭。

If you are lucky enough to control the back-end and can configure CORS headers, you will need to maintain a whitelist of multiple web clients accessing the API server in order to give them access. Of course, wildcard is also an option, but it would be unreasonable to whitelist all the origins by setting access-control-allow-origin to * unless it is a public server.

如果您足夠幸運地可以控制后端并可以配置CORS標頭，則需要維護一個訪問API服務器的多個Web客戶端的白名單，以便為其授予訪問權限。當然，通配符也是一個選項，但是除非將access-control-allow-origin為*除非它是公共服務器，否則將所有來源列入白名單是不合理的。

Another common pattern, during development, is to run our UI application at localhost:$port. But whitelisting localhost to facilitate API calls is an anti-pattern and should be avoided for security reasons.

在開發過程中，另一種常見模式是在localhost:$port運行我們的UI應用程序。但是將本地主機列入白名單以方便API調用是一種反模式，出于安全原因應避免使用。

Last, but not least, I like my build to conform to the Build Once, Deploy Many principle. It is one of the fundamental principles of continuous delivery. The binary — in our case, static files for the web client — is built only once. Subsequent deployments, testing, and releases should never attempt to build the binary artifacts again. Instead, the already built binary should be reused.

最后但并非最不重要的一點是，我希望我的構建符合“ 一次構建，多次部署”的原則。這是持續交付的基本原則之一。二進制文件(在我們的示例中是Web客戶端的靜態文件)僅生成一次。后續的部署，測試和發行版絕不應嘗試再次構建二進制工件。相反，應該重新使用已經構建的二進制文件。

In practice, hardcoded absolute URLs like https://api.appfocused.com/email/send in our client code will stop us from having a single artifact, because on development environment I want my web client to hit, say, https://api-dev.appfocused.com/email/send.

實際上，在客戶端代碼中使用諸如https://api.appfocused.com/email/send這樣的硬編碼絕對URL會阻止我們擁有單一工件，因為在開發環境中，我希望我的Web客戶端點擊例如https://api-dev.appfocused.com/email/send 。

Never hardcode an absolute API URL in your client code.
切勿在客戶端代碼中對絕對API URL進行硬編碼。

This became a powerful mantra for me and helped me to overcome some challenges on the way.

這成為我的強大口號，并幫助我克服了前進中的一些挑戰。

解 (Solution)

The relative URL /email/send can solve it once and for all on the client, making Build Once, Deploy Many possible. It is the proxy’s work to orchestrate the request further. It also deals with the restrictions imposed by the browser. The proxy server, in this case, handles our requests, responses, and makes the modifications necessary to facilitate cross-origin communication.

相對URL /email/send可以在客戶端上一勞永逸地解決它，從而使“一次構建，多次部署”成為可能。代理的工作是進一步協調請求。它還處理瀏覽器施加的限制。在這種情況下，代理服務器處理我們的請求，響應，并進行必要的修改以促進跨域通信。

反向代理與webpack-dev-server (Reverse proxy with webpack-dev-server)

When you are developing on your local machine, you want the same treatment for your API as on other environments. Webpack can be configured to proxy requests. An example “webpack.config.js” is:

在本地計算機上進行開發時，您希望對API的處理與在其他環境中相同。可以將Webpack配置為代理請求。示例“ webpack.config.js”為：

module.exports = {//...devServer: {proxy: {'/api': 'http://localhost:9000'}}
};

A request from the client to the relative path /api/users will now proxy the request to http://localhost:9000/api/users. Please check the Webpack documentation if you want to configure URL rewrite scenarios or add secure protocol.

客戶端對相對路徑/api/users的請求現在會將請求代理到http://localhost:9000/api/users 。如果要配置URL重寫方案或添加安全協議，請查閱W ebpack文檔。

The proxy can also be configured for projects built on Webpack like create-react-app or Gatsby.

還可以為基于Webpack的項目(如create-react-app或Gatsby)配置代理。

NGINX的反向代理 (Reverse proxy with NGINX)

NGINX is a common component in production environment architecture. It has a number of advanced load balancing, security, and acceleration features that most specialized applications lack. Using NGINX as a reverse proxy enables you to add these features to any application.

NGINX是生產環境體系結構中的常見組件。它具有大多數專業應用程序所缺少的許多高級負載平衡，安全性和加速功能。使用NGINX作為反向代理，可以將這些功能添加到任何應用程序中。

The simplest reverse proxy config on NGINX will look like this, in “/etc/nginx/conf.d/app.conf”

NGINX上最簡單的反向代理配置如下所示：“ / etc / nginx / conf.d / app.conf”

server {listen 80;listen [::]:80;server_name appfocused.com;location /api {proxy_pass http://api.appfocused.com/;}
}

The proxy_pass directive makes this configuration a reverse proxy. It specifies that all requests which match the location block — in this case, /api path — should be forwarded to http://api.appfocused.com, where our back-end is running.

proxy_pass指令使此配置成為反向代理。它指定所有與位置塊匹配的請求(在本例中為/api路徑)都應轉發到運行后端的http://api.appfocused.com 。

Check the full docs for some more elaborate scenarios.

查看完整的文檔，了解更多詳細的方案。

無服務器的反向代理 (Reverse proxy with serverless)

We will look at the AWS platform for a serverless scenario. In one of my previous posts I explained how we use serverless architecture to host our website. AWS CloudFront is playing one of the key roles in it, acting as CDN and providing security at the edge for our static files stored on S3.

我們將針對無服務器場景研究AWS平臺。在我以前的一篇文章中，我解釋了我們如何使用無服務器架構來托管我們的網站。 AWS CloudFront在其中扮演著關鍵角色之一，它充當CDN并在邊緣為存儲在S3上的靜態文件提供安全性。

The first API that we had to integrate into this setup was a contact form. The brief for implementation was the following:

我們必須集成到此設置中的第一個API是聯系表單。實施摘要如下：

When a client posts to https://www.appfocused.com/api/send/email, the request needs to be routed to https://api.appfocused.com/api/send/email where our back-end API is deployed in the form of Lambda function.
當客戶發布到https://www.appfocused.com/api/send/email ，請求需要路由到https://api.appfocused.com/api/send/email ，其中我們的后端API以Lambda函數的形式部署。

It turns out that CloudFront supports multiple origin servers. It uses path patterns to determine which origin server to forward requests to. Multiple independent servers, even systems that aren’t inside AWS, can all “own” one or more paths under a single hostname. One of them is the default and owning all the paths not explicitly configured.

事實證明，CloudFront支持多個原始服務器。它使用路徑模式來確定將請求轉發到哪個原始服務器。多個獨立的服務器，甚至不在AWS內的系統，都可以在一個主機名下“擁有”一個或多個路徑。其中之一是默認設置，它擁有未明確配置的所有路徑。

The concept is very similar to reverse proxies in NGINX or Apache. But the request routing is done by CloudFront, which connects to the appropriate back-end, sends the request, and returns — and possibly caches — the response. It does not redirect the request, so the URL address never changes for the consumer.

這個概念與NGINX或Apache中的反向代理非常相似。但是請求路由是由CloudFront完成的，CloudFront連接到適當的后端，發送請求，然后返回(可能還緩存)響應。它不會重定向請求，因此URL地址對于使用者永遠不會改變。

CloudFront配置示例 (CloudFront configuration example)

Use the main site’s hostname, for example www.appfocused.com, as the origin. Configure the site’s domain name as an alternate domain name in CloudFront.

使用主站點的主機名(例如www.appfocused.com )作為源。在CloudFront中將站點的域名配置為備用域名。

Next, add a second origin, with the destination being the hostname where the WP deployment can be reached. Create a behavior with a path pattern that matches /blog* and uses the second origin.

接下來，添加第二個來源，目標是可以到達WP部署的主機名。創建具有匹配/blog*并使用第二個來源的路徑模式的行為。

Our existing CloudFront distribution was set up to point to our static S3 bucket content generated by the great Gatsby. Remember not to use autosuggestion from AWS when creating a new distribution with integration to S3. Manually enter website endpoints similar to this format http://appfocused.s3-website.eu-west-1.amazonaws.com.

我們現有的CloudFront發行版已設置為指向由出色的蓋茨比生成的靜態S3存儲桶內容。請記住，在創建與S3集成的新發行版時不要使用來自AWS的自動建議。手動輸入類似于以下格式的網站端點 http://appfocused.s3-website.eu-west-1.amazonaws.com 。

Next, we’ll add our second origin to serve REST requests from API Gateway. From the “Origins” tab select “Create Origin”. Enter the domain name and leave origin path empty. Make sure to select “HTTPS only” for “Origin Protocol Policy”.

接下來，我們將添加第二個來源以服務來自API網關的REST請求。從“來源”選項卡中選擇“創建原點”。輸入域名，并將原始路徑留空。確保為“原始協議策略”選擇“僅HTTPS”。

Next go to the “Behaviors” tab and click “Create Behavior” to configure the path.

接下來轉到“行為”選項卡，然后單擊“創建行為”以配置路徑。

For “Path Pattern” we’ll use api/* . This will catch any request starting with /api such as https://www.appfocused.com/api/send/email.

對于“路徑模式”，我們將使用api/* 。這將捕獲以/api開頭的任何請求，例如https://www.appfocused.com/api/send/email 。

In the “Origin” dropdown select the Origin we just created. This will ensure that the request will be routed to https://api.appfocused.com/api/send/email.

在“來源”下拉列表中，選擇我們剛剛創建的來源。這將確保將請求路由到https://api.appfocused.com/api/send/email 。

For “Viewer Protocol Policy” select “HTTPS only”.

對于“查看器協議策略”，選擇“僅HTTPS”。

For “Allowed HTTP methods” select “GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE”.

對于“允許的HTTP方法”，選擇“獲取，標題，選項，輸入，張貼，修補，刪除”。

For “Cache Based on Selected Request Headers” select “Whitelist” and add required headers. This prevents the Host Header being passed through to the origin.

對于“基于所選請求標頭的緩存”，選擇“白名單”并添加所需的標頭。這樣可以防止主機頭傳遞到源。

For “Object Caching” select “Use Origin Cache Headers”.

對于“對象緩存”，選擇“使用原始緩存頭”。

For “Forward Cookies” select “All”.

對于“轉發Cookie”，選擇“全部”。

For “Compress Objects Automatically” select “Yes”. This will gzip responses.

對于“自動壓縮對象”，選擇“是”。這將gzip響應。

CloudFront forwards very few headers to the origin by default. You can configure it to forward what you need, but every header you forward will reduce your cache hit ratio. Personally I’m passing through “Referer”, “Accept”, “Content-Type”, and “Authorization”.

默認情況下，CloudFront會將很少的標頭轉發到源。您可以將其配置為轉發所需的內容，但是轉發的每個標頭都會降低緩存的命中率。我個人是通過“引薦來源網址”，“接受”，“內容類型”和“授權”。

There are some caveats, though, to the serverless proxy on AWS. CloudFront won’t strip paths.

但是，AWS上的無服務器代理有一些警告。 CloudFront不會刪除路徑。

If a request is sent to https://www.appfocused.com/api/* it will be routed to https://api.appfocused.comwith the /api prefix, not to the root of the site.

如果請求被發送到https://www.appfocused.com/api/*將被路由到https://api.appfocused.com 與該/api網站的前綴，而不是根源。

This can become an issue if you don’t own back-end APIs or, for some reasons, these cannot be changed. If that’s the case, Lambda@Edge comes to the rescue. This service allows you to rewrite paths on the fly, as requests are processed. To configure Lambda@Edge go to CloudFront Behavior item and choose “Lambda Function Associations”.

如果您不擁有后端API，或者由于某些原因而無法更改這些API，這可能會成為一個問題。如果是這樣， Lambda @ Edge可以進行救援。此服務使您可以在處理請求時即時重寫路徑。要配置Lambda @ Edge，請轉到CloudFront行為項目，然后選擇“ Lambda函數關聯”。

結論 (Conclusion)

By implementing reverse proxy across environments we achieve:

通過跨環境實現反向代理，我們可以實現：

Secure client-server communication
安全的客戶端-服務器通信

the identity of your back-end servers remains unknown. This is useful in case of DDoS attacks
后端服務器的身份仍然未知。這在DDoS攻擊時很有用
Build Once, Deploy Many
一次構建，多次部署

with relative paths to APIs you can build once, and deploy the same artifact to multiple environments
通過API的相對路徑，您可以構建一次，然后將同一工件部署到多個環境
Same Origin
同源

a CORS headers configuration on the server is not required
不需要服務器上的CORS標頭配置

My personal advice is: never hardcode absolute paths to your APIs again, unless it is a prototype. Spend a bit more time to configure a reverse proxy layer to make it right.

我的個人建議是：除非它是原型，否則不要再對您的API的絕對路徑進行硬編碼。花更多的時間來配置反向代理層以使其正確。

This post was originally published on my company’s blog. Our mission at Appfocused is to help companies execute great user experiences on the web by utilising our vast experience, knowledge of the modern UI trends, best practices, and code craftsmanship.

該帖子最初發布在我公司的博客上。 Appfocused的使命是通過利用我們的豐富經驗，對現代UI趨勢的知識，最佳實踐和代碼制作技巧，幫助公司在網絡上執行出色的用戶體驗。