Tham chiếu cấu hình proxy API

Bạn đang xem tài liệu về Apigee Edge.
Chuyển đến tài liệu về Apigee X. thông tin

Là một nhà phát triển đang làm việc với Apigee Edge, các hoạt động phát triển chính của bạn liên quan đến việc định cấu hình các proxy API có chức năng làm proxy cho API hoặc dịch vụ phụ trợ. Tài liệu này là tài liệu tham khảo tất cả phần tử cấu hình có sẵn cho bạn khi tạo proxy API.

Nếu đang tìm hiểu cách tạo proxy API, bạn nên bắt đầu với chủ đề Tạo proxy API đơn giản.

Cách phổ biến nhất để chỉnh sửa cấu hình proxy là:

• Sử dụng trình chỉnh sửa XML trong giao diện người dùng Edge
• Tải cấu hình xuống và chỉnh sửa cục bộ, như mô tả trong bài viết Phát triển cục bộ cấu hình proxy.

Phát triển cục bộ cấu hình proxy

Bạn có thể tải các cấu hình proxy xuống để có thể chỉnh sửa chúng trên máy cục bộ. Khi hoàn tất, hãy tải kết quả lên Edge. Phương pháp này cho phép bạn tích hợp các cấu hình proxy vào quy trình kiểm soát nguồn, tạo phiên bản và các quy trình làm việc dùng chung khác. Ngoài ra, bằng cách xử lý cấu hình proxy cục bộ, bạn có thể sử dụng các công cụ xác thực và trình chỉnh sửa XML của riêng mình.

Phần này mô tả cách sử dụng giao diện người dùng để tải dữ liệu cấu trúc proxy hiện có xuống, chỉnh sửa rồi tải lại lên Edge để triển khai. Bạn cũng có thể sử dụng apigeetool để tải xuống và triển khai cấu hình proxy mới (bằng cách dùng lệnh fetchproxy và deployproxy tương ứng).

Cách chỉnh sửa cấu hình proxy cục bộ bằng giao diện người dùng:

1. Tải cấu hình proxy hiện tại xuống trong giao diện người dùng Edge. (Trong chế độ xem Proxy API, hãy chọn Dự án > Tải bản sửa đổi xuống.)
2. Trên máy cục bộ, hãy tạo một thư mục mới và mở rộng tệp ZIP đã tải xuống vào thư mục đó.

   Để mở rộng tệp ZIP, bạn có thể sử dụng một tiện ích như unzip, như minh hoạ trong ví dụ sau:

   mkdir myappdir
   unzip ./my-app_app_rev3_2019_04_20.zip -d myappdir

   Nội dung mở rộng của tệp ZIP phải tương tự như cấu trúc mô tả trong cấu trúc proxy API.

3. Chỉnh sửa các tệp nguồn nếu cần. Để biết nội dung mô tả về các tệp nguồn trong cấu hình proxy, hãy xem phần Tệp cấu hình và cấu trúc thư mục của proxy API.

   Ví dụ: để bật tính năng theo dõi tình trạng trong proxy API, hãy chỉnh sửa tệp cấu hình TargetEndpoint trong thư mục /apiproxy/targets/. Tệp mặc định trong thư mục này là default.xml, mặc dù có thể có các tệp có tên khác nhau nếu bạn sử dụng mục tiêu có điều kiện.

   Trong trường hợp này, nếu tệp cấu hình TargetEndpoint và thư mục của tệp đó không tồn tại, hãy tạo các tệp đó.

4. Sau khi bạn hoàn tất chỉnh sửa tệp cấu hình proxy, hãy nhớ lưu các thay đổi của mình.
5. Đổi sang thư mục mới mà bạn đã tạo khi mở rộng tệp ZIP (gốc của các tệp cấu hình mở rộng).

   Ví dụ: nếu bạn mở rộng các tệp vào thư mục /myappdir, hãy đổi sang thư mục đó, như ví dụ sau đây:

   cd myappdir

   Bạn nên chuyển sang thư mục này trước khi lưu trữ lại các tệp cấu hình proxy vì bạn không muốn đưa thư mục /myappdir vào tệp ZIP. Thư mục cấp cao nhất trong tệp ZIP phải là /apiproxy.

6. Lưu trữ lại các tệp cấu hình proxy, bao gồm các tệp mới hoặc đã thay đổi. Bạn có thể sử dụng một tiện ích như zip, như trong ví dụ sau:

   zip my-new-proxy.zip -r .

   Thư mục cấp cao nhất trong tệp ZIP phải là /apiproxy.

   Không có yêu cầu đặc biệt nào đối với tên tệp ZIP. Ví dụ: bạn không cần tăng số bản sửa đổi hoặc chỉ định ngày trong tên tệp, nhưng việc này có thể hữu ích khi gỡ lỗi hoặc kiểm soát nguồn.

   Edge tăng số lần sửa đổi cấu hình proxy mới cho bạn khi bạn tải cấu hình đó lên.

7. Tải cấu hình proxy mới lên bằng giao diện người dùng Edge. (Trong chế độ xem API Proxy, chọn Dự án > Tải bản sửa đổi mới lên.)

   Nếu bạn gặp lỗi như Bundle is invalid. Empty bundle., hãy đảm bảo thư mục cấp cao nhất của tệp ZIP là /apiproxy. Nếu không, hãy lưu trữ lại các tệp cấu hình proxy của bạn từ gốc của thư mục mở rộng.

   Sau khi tải cấu hình proxy mới lên, Edge sẽ tăng số bản sửa đổi và hiển thị số đó trong chế độ xem Revision Summary (Tóm tắt bản sửa đổi).

   Edge không triển khai bản sửa đổi mới cho bạn sau khi bạn tải bản sửa đổi đó lên bằng giao diện người dùng.

8. Triển khai bản sửa đổi mới.

Để biết thêm thông tin, hãy xem phần Hướng dẫn: Cách tải proxy xuống bằng giao diện người dùng và API quản lý trong Cộng đồng API.

Cấu trúc proxy API

Proxy API bao gồm cấu hình sau:

Cấu trúc và nội dung của thư mục proxy API

Các thành phần trong bảng trên được xác định bởi các tệp cấu hình trong cấu trúc thư mục sau:

Tệp cấu hình và cấu trúc thư mục của proxy API

Phần này giải thích các tệp cấu hình và cấu trúc thư mục của proxy API.

• Cấu hình cơ sở
• ProxyEndpoint
• TargetEndpoint
  • Cấu hình điểm cuối TLS/SSL
• Chính sách
• Luồng
• Tài nguyên

Cấu hình cơ sở

/apiproxy/weatherapi.xml

Cấu hình cơ sở của một proxy API, giúp xác định tên của proxy API. Tên phải là duy nhất trong một tổ chức.

Cấu hình mẫu:

<APIProxy name="weatherapi">
</APIProxy>

Phần tử cấu hình cơ sở

ProxyEndpoint

Hình ảnh sau đây cho thấy quy trình yêu cầu/phản hồi:

/apiproxy/proxies/default.xml

Cấu hình ProxyEndpoint xác định giao diện đến (trực tiếp với máy khách) cho một proxy API. Khi định cấu hình ProxyEndpoint, bạn đang thiết lập cấu hình mạng giúp xác định cách các ứng dụng khách ("ứng dụng") sẽ gọi API proxy.

Cấu hình ProxyEndpoint mẫu sau đây sẽ được lưu trữ trong /apiproxy/proxies:

<ProxyEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <VirtualHost>default</VirtualHost>
  </HTTPProxyConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <RouteRule name="default">
    <TargetEndpoint>default</TargetEndpoint>
  </RouteRule>
</ProxyEndpoint>

Các phần tử cấu hình bắt buộc trong một ProxyEndpoint cơ bản là:

Phần tử cấu hình ProxyEndpoint

Cách định cấu hình RouteRules

TargetEndpoint có tên là một tệp cấu hình trong /apiproxy/targets mà RouteRule sẽ chuyển tiếp một yêu cầu sau khi được ProxyEndpoint xử lý.

Ví dụ: RouteRule sau đây đề cập đến cấu hình /apiproxy/targets/myTarget.xml:

<RouteRule name="default">
  <TargetEndpoint>myTarget</TargetEndpoint>
</RouteRule>

Gọi URL trực tiếp

ProxyEndpoint cũng có thể gọi trực tiếp một dịch vụ phụ trợ. Lệnh gọi URL trực tiếp sẽ bỏ qua bất kỳ cấu hình TargetEndpoints nào có tên trong /apiproxy/targets. Vì lý do này, TargetEndpoint là một cấu hình proxy API không bắt buộc, mặc dù trên thực tế, bạn không nên gọi trực tiếp từ ProxyEndpoint.

Ví dụ: RouteRule sau đây sẽ thực hiện lệnh gọi HTTP đến http://api.mycompany.com/v2.

<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL> 
</RouteRule>

Tuyến đường có điều kiện

RouteRules có thể được tạo chuỗi để hỗ trợ định tuyến động trong thời gian chạy. Các yêu cầu đến có thể được chuyển thẳng đến các cấu hình TargetEndpoint có tên, trực tiếp đến URL hoặc kết hợp cả hai dựa trên tiêu đề HTTP, nội dung thông báo, tham số truy vấn hoặc thông tin theo ngữ cảnh như thời gian trong ngày, ngôn ngữ, v.v.

RouteRules có điều kiện hoạt động giống như các câu lệnh có điều kiện khác trên Apigee Edge. Xem bài viết Tài liệu tham khảo về điều kiện và Tài liệu tham khảo về biến.

Ví dụ: trước tiên, tổ hợp RouteRule sau đây sẽ đánh giá yêu cầu đến để xác minh giá trị của tiêu đề HTTP. Nếu tiêu đề HTTP routeTo có giá trị TargetEndpoint1, thì yêu cầu sẽ được chuyển tiếp đến TargetEndpoint có tên là TargetEndpoint1. Nếu không, yêu cầu đến sẽ được chuyển tiếp đến http://api.mycompany.com/v2.

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL>
</RouteRule>

Tuyến rỗng

Bạn có thể xác định RouteRule rỗng để hỗ trợ các trường hợp trong đó thông báo yêu cầu không cần được chuyển tiếp đến TargetEndpoint. Điều này rất hữu ích khi ProxyEndpoint thực hiện tất cả các quá trình xử lý cần thiết, chẳng hạn như bằng cách sử dụng JavaScript để gọi một dịch vụ bên ngoài hoặc truy xuất dữ liệu qua một lượt tra cứu đến kho khoá/giá trị của Dịch vụ API.

Ví dụ: nội dung sau đây xác định một Tuyến rỗng:

<RouteRule name="GoNowhere"/>

Tuyến rỗng có điều kiện có thể hữu ích. Trong ví dụ sau, một Tuyến rỗng được định cấu hình để thực thi khi tiêu đề HTTP request.header.X-DoNothing có một giá trị không phải là null.

<RouteRule name="DoNothingOnDemand">
  <Condition>request.header.X-DoNothing != null</Condition>
</RouteRule>

Hãy nhớ rằng RouteRules có thể được tạo chuỗi, vì vậy, Tuyến đường rỗng có điều kiện thường sẽ là một thành phần của tập hợp RouteRules được thiết kế để hỗ trợ việc định tuyến có điều kiện.

Việc sử dụng trong thực tế Tuyến đường rỗng có điều kiện sẽ hỗ trợ việc lưu vào bộ nhớ đệm. Bằng cách sử dụng giá trị của biến do chính sách Bộ nhớ đệm đặt, bạn có thể định cấu hình proxy API để thực thi Tuyến rỗng khi một mục nhập được phân phát từ bộ nhớ đệm.

<RouteRule name="DoNothingUnlessTheCacheIsStale">
  <Condition>lookupcache.LookupCache-1.cachehit is true</Condition>
</RouteRule>

TargetEndpoint

TargetEndpoint tương đương với một ProxyEndpoint. TargetEndpoint hoạt động như máy khách tới một dịch vụ phụ trợ hoặc API – ứng dụng này sẽ gửi yêu cầu và nhận phản hồi.

Proxy API không cần có TargetEndpoints. Bạn có thể định cấu hình ProxyEndpoints để gọi URL trực tiếp. Một proxy API không có TargetEndpoints thường chứa một ProxyEndpoint trực tiếp gọi một dịch vụ phụ trợ hoặc được định cấu hình để gọi một dịch vụ bằng Java hoặc JavaScript.

Cấu hình TargetEndpoint

/targets/default.xml

TargetEndpoint xác định kết nối ra ngoài từ Apigee Edge đến một dịch vụ hoặc tài nguyên khác.

Dưới đây là cấu hình TargetEndpoint mẫu:

<TargetEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <SSLInfo/>
  </HTTPTargetConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <ScriptTarget/>
  <LocalTargetConnection/>
</TargetEndpoint>

Phần tử cấu hình TargetEndpoint

TargetEndpoint có thể gọi mục tiêu theo một trong các cách sau:

• HTTPTargetConnection cho lệnh gọi HTTP(S)
• LocalTargetConnection cho chuỗi proxy đến proxy cục bộ
• ScriptTarget cho các lệnh gọi đến tập lệnh Node.js được lưu trữ ở Edge

Chỉ định cấu hình một trong những giá trị này trong TargetEndpoint.

Cấu hình điểm đầu cuối TLS/SSL

TargetEndpoints thường cần quản lý các kết nối HTTPS bằng cơ sở hạ tầng phụ trợ không đồng nhất. Vì lý do này, một số chế độ cài đặt cấu hình TLS/SSL được hỗ trợ.

Phần tử cấu hình TargetEndpoint TLS/SSL

<Ciphers>
 <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>    
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>

<Protocols>
 <Protocol>TLSv1.1</Protocol>
 <Protocol>TLSv1.2</Protocol>
</Protocols>

<CommonName wildcardMatch="true">*.myhost.com</CommonName>

TargetEndpoint mẫu với xác thực ứng dụng đi được bật

<TargetEndpoint name="default">
  <HttpTargetConnection>
        <URL>https://myservice.com</URL>
    <SSLInfo>
      <Enabled>true</Enabled>
      <ClientAuthEnabled>true</ClientAuthEnabled>
      <KeyStore>myKeystore</KeyStore>
      <KeyAlias>myKey</KeyAlias>
      <TrustStore>myTruststore</TrustStore>
    </SSLInfo>
  </HttpTargetConnection>
</TargetEndpoint>

Để biết hướng dẫn chi tiết, hãy xem bài viết Định cấu hình TLS từ Edge đến phần phụ trợ (Đám mây và đám mây riêng tư).

Sử dụng các biến luồng để đặt giá trị TLS/SSL theo cách động

Bạn cũng có thể tự động thiết lập thông tin về TLS/SSL để hỗ trợ các yêu cầu linh hoạt về thời gian chạy. Ví dụ: nếu proxy của bạn kết nối với 2 mục tiêu có thể khác nhau (một mục tiêu kiểm thử và một mục tiêu sản xuất), thì bạn có thể dùng proxy API theo phương thức lập trình để phát hiện môi trường mà proxy đó đang gọi và tự động đặt các tệp tham chiếu đến kho khoá và kho lưu trữ tin cậy thích hợp. Bài viết sau đây trên Cộng đồng Apigee sẽ giải thích chi tiết hơn về trường hợp này và cung cấp các ví dụ về proxy API có thể triển khai: https://community.apigee.com/articles/21424/dynamic-sslinfo-for-targetendpoint-using-variable.html.

Trong ví dụ sau đây về cách đặt thẻ <SSLInfo> trong cấu hình TargetEndpoint, bạn có thể cung cấp các giá trị trong thời gian chạy, ví dụ: bằng Chú thích Java, chính sách JavaScript hoặc chính sách Chỉ định thông báo. Hãy sử dụng bất kỳ biến thông báo nào có chứa các giá trị bạn muốn đặt.

Biến chỉ được phép trong các phần tử sau đây.

<SSLInfo>
    <Enabled>{myvars.ssl.enabled}</Enabled>
    <ClientAuthEnabled>{myvars.ssl.client.auth.enabled}</ClientAuthEnabled>
    <KeyStore>{myvars.ssl.keystore}</KeyStore>
    <KeyAlias>{myvars.ssl.keyAlias}</KeyAlias>
    <TrustStore>{myvars.ssl.trustStore}</TrustStore>
</SSLInfo>

Sử dụng tệp tham chiếu để đặt động các giá trị TLS/SSL

Khi định cấu hình một TargetEndpoint sử dụng HTTPS, bạn phải xem xét trường hợp mà chứng chỉ TLS/SSL hết hạn hoặc việc thay đổi cấu hình hệ thống yêu cầu bạn cập nhật chứng chỉ. Trong quá trình cài đặt Edge dành cho đám mây riêng tư, khi định cấu hình TLS/SSL bằng cách dùng các giá trị tĩnh hoặc dùng các biến luồng, có thể bạn sẽ phải khởi động lại Bộ xử lý thư.

Để biết thêm thông tin, hãy xem phần Cập nhật chứng chỉ TLS.

Tuy nhiên, bạn có thể tuỳ ý định cấu hình TargetEndpoint để sử dụng một tệp tham chiếu đến kho khoá hoặc kho lưu trữ tin cậy. Ưu điểm của việc sử dụng tệp tham chiếu là bạn có thể cập nhật tệp tham chiếu để trỏ đến một kho khoá hoặc kho tin cậy khác nhằm cập nhật chứng chỉ TLS/SSL mà không cần phải khởi động lại Bộ xử lý thông báo.

Ví dụ: dưới đây là một TargetEndpoint sử dụng tham chiếu đến kho khoá:

<SSLInfo> 
    <Enabled>true</Enabled> 
    <ClientAuthEnabled>false</ClientAuthEnabled> 
    <KeyStore>ref://keystoreref</KeyStore> 
    <KeyAlias>myKeyAlias</KeyAlias> 
</SSLInfo>

Sử dụng lệnh gọi API POST sau đây để tạo tệp tham chiếu có tên keystoreref:

curl -X POST  -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references \
-d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>' -u email:password

Tệp đối chiếu chỉ định tên kho khoá và loại kho khoá.

Hãy sử dụng lệnh gọi GET API sau đây để xem tài liệu tham khảo:

curl -X GET https://api.enterprise.apigee.com/v1/o/[org_name}/e/{env_name}/references/keystoreref -u uname:password

Để sau này thay đổi tham chiếu nhằm trỏ đến một kho khoá khác, hãy đảm bảo rằng bí danh có cùng tên, hãy sử dụng lệnh gọi PUT sau:

curl -X PUT -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references/keystoreref \
-d '<ResourceReference name="keystoreref">
    <Refers>myNewKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>' -u email:password

TargetEndpoint với tính năng cân bằng tải mục tiêu

TargetEndpoints hỗ trợ cân bằng tải trên nhiều TargetServers được đặt tên bằng cách sử dụng 3 thuật toán cân bằng tải.

Để biết hướng dẫn chi tiết, hãy tham khảo bài viết Cân bằng tải trên các máy chủ phụ trợ.

Chính sách

Thư mục /policies trong proxy API chứa tất cả chính sách có thể đính kèm vào Luồng trong proxy API.

Phần tử cấu hình chính sách

Tệp đính kèm chính sách

Hình ảnh sau đây minh hoạ trình tự thực thi luồng proxy API:

Như đã trình bày ở trên:

Các chính sách được đính kèm dưới dạng các bước xử lý cho Flow. Tên của chính sách dùng để tham chiếu đến chính sách sẽ được thực thi dưới dạng một Bước xử lý. Tệp đính kèm chính sách có định dạng như sau:

<Step><Name>MyPolicy</Name></Step>

Các chính sách được thực thi theo thứ tự đính kèm vào một Quy trình. Ví dụ:

<Step><Name>FirstPolicy</Name></Step>
<Step><Name>SecondPolicy</Name></Step>

Phần tử cấu hình tệp đính kèm chính sách

Quy trình

ProxyEndpoint và TargetEndpoint xác định một quy trình để xử lý thông báo yêu cầu và phản hồi. Quy trình xử lý bao gồm một quy trình yêu cầu và một quy trình phản hồi. Mỗi quy trình yêu cầu và quy trình phản hồi được chia nhỏ thành một PreFlow, một hoặc nhiều quy trình "có điều kiện" hoặc "được đặt tên" (không bắt buộc) và một PostFlow.

• PreFlow: Luôn thực thi. Thực thi trước bất kỳ Luồng có điều kiện nào.
• PostFlow: Luôn thực thi. Thực thi sau bất kỳ Luồng có điều kiện nào.

Ngoài ra, bạn có thể thêm PostClientFlow vào ProxyEndpoint. Quá trình này sẽ thực thi sau khi phản hồi được trả về ứng dụng yêu cầu. Bạn chỉ có thể đính kèm chính sáchMessageLogging và Tiện ích ghi nhật ký Stackdriver của Google vào quy trình này. PostClientFlow giảm độ trễ proxy API và cung cấp thông tin để ghi nhật ký những thông tin chưa được tính cho đến khi phản hồi được trả về ứng dụng, chẳng hạn như client.sent.start.timestamp và client.sent.end.timestamp.Luồng này được dùng chủ yếu để đo khoảng thời gian giữa dấu thời gian bắt đầu và kết thúc cho thông báo phản hồi.

Xem video hướng dẫn nhanh

Dưới đây là ví dụ về PostClientFlow có đính kèm chính sách ghi nhật ký thông báo.

    ...
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <PostClientFlow>
        <Request/>
        <Response>
            <Step>
                <Name>Message-Logging-1</Name>
            </Step>
        </Response>
    </PostClientFlow>
    ...

Quy trình xử lý proxy API thực thi Luồng theo trình tự sau đây:

Quy trình yêu cầu:

1. Yêu cầu proxy trước luồng
2. Luồng có điều kiện của yêu cầu proxy (Không bắt buộc)
3. Yêu cầu proxy sau luồng
4. PreFlow của yêu cầu mục tiêu
5. Luồng có điều kiện của yêu cầu mục tiêu (Không bắt buộc)
6. Yêu cầu mục tiêu PostFlow

Quy trình phản hồi:

1. PreFlow của phản hồi mục tiêu
2. Luồng có điều kiện của phản hồi mục tiêu (Không bắt buộc)
3. PostFlow của phản hồi mục tiêu
4. Tiền phản hồi proxy
5. Luồng có điều kiện phản hồi proxy (Không bắt buộc)
6. Phản hồi proxy PostFlow
7. Phản hồi PostClientFlow (Không bắt buộc)

Bạn chỉ cần định cấu hình cho những Luồng có tệp đính kèm chính sách trong cấu hình ProxyEndpoint hoặc TargetEndpoint. Bạn chỉ cần chỉ định PreFlow và PostFlow trong cấu hình ProxyEndpoint hoặc TargetEndpoint khi cần thực thi chính sách trong quá trình xử lý PreFlow hoặc PostFlow.

Khác với luồng có điều kiện, thứ tự của các phần tử PreFlow và PostFlow không quan trọng – proxy API sẽ luôn thực thi từng phần tử tại một thời điểm thích hợp trong quy trình, bất kể vị trí của các phần tử đó trong cấu hình Điểm cuối.

Luồng có điều kiện

ProxyEndpoints và TargetEndpoints hỗ trợ số lượng luồng có điều kiện không giới hạn (còn gọi là "luồng được đặt tên").

Kiểm thử proxy API cho điều kiện được chỉ định trong luồng có điều kiện và nếu điều kiện đó được đáp ứng thì các bước xử lý trong luồng có điều kiện sẽ được proxy API thực thi. Nếu không đáp ứng điều kiện, thì các bước xử lý trong luồng có điều kiện sẽ bị bỏ qua. Luồng có điều kiện được đánh giá theo thứ tự đã xác định trong proxy API và luồng đầu tiên đáp ứng điều kiện sẽ được thực thi.

Bằng cách xác định luồng có điều kiện, bạn có thể áp dụng các bước xử lý trong proxy API dựa trên:

• URI yêu cầu
• Động từ HTTP (GET/PUT/POST/DELETE)
• Giá trị của tham số truy vấn, tiêu đề và tham số biểu mẫu
• Nhiều loại điều kiện khác

Ví dụ: luồng có điều kiện sau đây xác định rằng luồng này chỉ được thực thi khi đường dẫn tài nguyên yêu cầu là /accesstoken. Mọi yêu cầu đến có đường dẫn /accesstoken đều sẽ được thực thi luồng này, cùng với mọi chính sách được đính kèm vào flow này. Nếu đường dẫn yêu cầu không chứa hậu tố /accesstoken, thì quy trình sẽ không thực thi (mặc dù một quy trình có điều kiện khác có thể).

<Flows>
  <Flow name="TokenEndpoint">
    <Condition>proxy.pathsuffix MatchesPath "/accesstoken"</Condition>
    <Request>
      <Step>
        <Name>GenerateAccessToken</Name>
      </Step>
    </Request> 
  </Flow>
</Flows>   

Phần tử cấu hình luồng

Xử lý bước

Apigee Edge thực thi thứ tự tuần tự của các Luồng có điều kiện. Luồng có điều kiện thực thi từ trên xuống dưới. Luồng có điều kiện đầu tiên có điều kiện đánh giá là true sẽ được thực thi và chỉ một Luồng có điều kiện được thực thi.

Ví dụ: trong cấu hình Flow sau, mọi yêu cầu đến không bao gồm hậu tố đường dẫn /first hoặc /second đều sẽ khiến ThirdFlow thực thi và thực thi chính sách có tên là Return404.

<Flows>
  <Flow name="FirstFlow">
    <Condition>proxy.pathsuffix MatchesPath "/first"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="SecondFlow">
    <Condition>proxy.pathsuffix MatchesPath "/second"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
      <Step><Name>SecondPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="ThirdFlow">
    <Request>
      <Step><Name>Return404</Name></Step>
    </Request>
  </Flow>
</Flows>

Tài nguyên

"Tài nguyên" (tệp tài nguyên để sử dụng trong proxy API) là các tập lệnh, mã và các biến đổi SMTP có thể được đính kèm vào Luồng bằng chính sách. Các tập lệnh này xuất hiện trong mục "Tập lệnh" của trình chỉnh sửa proxy API trong giao diện người dùng quản lý.

Xem phần Tệp tài nguyên để biết các loại tài nguyên được hỗ trợ.

Tài nguyên có thể được lưu trữ trong proxy API, môi trường hoặc tổ chức. Trong mỗi trường hợp, một tài nguyên sẽ được tham chiếu theo tên trong một Chính sách. Dịch vụ API phân giải tên bằng cách chuyển từ proxy API sang môi trường sang cấp tổ chức.

Chính sách có thể tham chiếu tài nguyên được lưu trữ ở cấp tổ chức trong bất kỳ môi trường nào. Chính sách trong môi trường đó có thể tham chiếu tài nguyên được lưu trữ ở cấp môi trường. Chỉ các Chính sách trong proxy API đó mới có thể tham chiếu tài nguyên được lưu trữ ở cấp proxy API.