api工廠接口路徑是什麼_為什麼（幾乎）永遠不要再使用絕對路徑通路API

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.com

with 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, [email protected] comes to the rescue. This service allows you to rewrite paths on the fly, as requests are processed. To configure [email protected] 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趨勢的知識，最佳實踐和代碼制作技巧，幫助公司在網絡上執行出色的使用者體驗 。

翻譯自: https://www.freecodecamp.org/news/never-use-an-absolute-path-for-your-apis-again-9ee9199563be/

api工廠接口路徑是什麼