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 làm việc với Apigee Edge, các hoạt động phát triển chính của bạn bao gồm định cấu hình proxy API hoạt động dưới dạng proxy cho API hoặc dịch vụ phụ trợ. Tài liệu này là một tài liệu tham khảo về tất cả cá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ủ đề Xây dựng một API đơn giản proxy.

Các 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 xuống và chỉnh sửa cấu hình trên máy, như được mô tả trong phần Cục bộ phát triển cấu hình proxy.

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

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

Phần này mô tả cách sử dụng giao diện người dùng để tải xuống, chỉnh sửa cấu trúc proxy hiện có, sau đó 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 sử dụng fetchproxy và deployproxy.)

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 các proxy API khung hiển thị, chọn Project (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 thành nó.

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

   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 giống với cấu trúc đượ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. Để có nội dung mô tả về các tệp nguồn trong proxy cấu hình, xem Tệp cấu hình và cấu trúc thư mục của proxy API.

   Ví dụ: để bật giám sát sức khoẻ ở proxy API của bạn, 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 với tên khác 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, tạo chúng.

4. Sau khi hoàn tất việc chỉnh sửa các tệp cấu hình proxy, hãy đảm bảo bạn lưu các thay đổi của mình.
5. Thay đổi sang thư mục mới mà bạn đã tạo khi mở rộng tệp ZIP (thư mục 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 thay đổi thành thư mục đó, như trong ví dụ sau đây:

   cd myappdir

   Bạn nên đổi 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ác tệp mới hoặc tệp đã thay đổi. Bạn có thể sử dụng phần mềm tiện ích như zip, trong ví dụ sau đây:

   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 cho 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 làm điều này có thể hữu ích cho việc gỡ lỗi hoặc kiểm soát nguồn.

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

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

   Nếu bạn gặp một lỗi như Bundle is invalid. Empty bundle., hãy đảm bảo rằng 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 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 tăng số bản sửa đổi và hiển thị báo cáo đó trong chế độ xem Revision Summary (Tóm tắt về 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 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 Apigee.

Cấu trúc proxy API

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

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

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 phần sau cấu trúc thư mục:

Tệp và thư mục cấu hình cấu trú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 đích 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 proxy API, xác định tên của proxy API. Tên phải là duy nhất trong 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 (dành cho máy khách) của một API proxy. Khi định cấu hình ProxyEndpoint, bạn đang thiết lập cấu hình mạng xác định cách các ứng dụng khách ("apps") gọi API qua 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à:

Cấu hình điểm cuối proxy Elements

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

TargetEndpoint có tên là một tệp cấu hình trong /apiproxy/targets để 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ể trực tiếp gọi một dịch vụ phụ trợ. Lệnh gọi URL trực tiếp sẽ bỏ qua mọi có tên là cấu hình TargetEndpoints 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ế, lệnh gọi trực tiếp từ ProxyEndpoint, bạn không nên sử dụng.

Ví dụ: RouteRule sau đây 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 xâu chuỗi để hỗ trợ định tuyến động trong thời gian chạy. Yêu cầu đến có thể là được định tuyến đến cấu hình TargetEndpoint đã đặt tên, trực tiếp đến URL hoặc đến một tổ hợp cả hai, dựa trên tiêu đề HTTP, nội dung thư, tham số truy vấn hoặc thông tin theo ngữ cảnh như thời gian 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. Hãy xem 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ụ: tổ hợp RouteRule sau đây sẽ đánh giá yêu cầu đến để xác minh trước giá trị của tiêu đề HTTP. Nếu tiêu đề HTTP routeTo có giá trị TargetEndpoint1, sau đó yêu cầu được chuyển tiếp đến TargetEndpoint có tên là TargetEndpoint1 Nếu không thì 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

Có thể xác định RouteRule rỗng để hỗ trợ các trường hợp mà 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ả 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 từ tra cứu đến Dịch vụ API kho khoá/giá trị.

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

<RouteRule name="GoNowhere"/>

Các 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ó giá trị khác với null

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

Hãy nhớ rằng RouteRules có thể được xâu chuỗi, vì vậy, một Tuyến 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 tuyến đường rỗng có điều kiện trong thực tế sẽ hỗ trợ chức năng lưu vào bộ nhớ đệm. Bằng cách sử dụng giá trị của biến được đặt bởi Chính sách bộ nhớ đệm, bạn có thể định cấu hình proxy API để thực thi Định 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 là đường đi tương đương với ProxyEndpoint. TargetEndpoint có chức năng là máy khách đến dịch vụ phụ trợ hoặc API – dịch vụ này gửi yêu cầu và nhận phản hồi.

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

Cấu hình điểm cuối đích

/targets/default.xml

TargetEndpoint xác định kết nối đi từ Apigee Edge đến một dịch vụ khác hoặc nguồn.

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>

Cấu hình điểm cuối đích Elements

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

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

Chỉ định cấu hình một trong các chỉ số này trong TargetEndpoint.

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

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

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

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

Mẫu TargetEndpoint khi bật tính năng xác thực ứng dụng đi

<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 Đị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 một cách linh động

Bạn cũng có thể tự động thiết lập chi tiết 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 hai mục tiêu có thể khác nhau (mục tiêu thử nghiệm và mục tiêu mục tiêu chính thức), bạn có thể thiết lập proxy API theo phương thức lập trình để phát hiện môi trường đó gọi cũng như đặt động các tham chiếu đến kho khoá và kho tin cậy thích hợp. Nội dung sau đây Bài viết trên Cộng đồng Apigee giải thích trường hợp này chi tiết hơn và cung cấp các API có thể triển khai ví dụ về proxy: https://community.apigee.com/articles/21424/dynamic-sslinfo-for-targetendpoint-using-variable.html.

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

Biến chỉ được phép trong những 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 các tham chiếu để đặt giá trị TLS/SSL một cách linh động

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

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

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

Ví dụ: dưới đây là một TargetEndpoint sử dụng một tệp 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 để tạo 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 tham chiếu chỉ định tên và loại của kho khoá.

Sử dụng lệnh gọi API GET sau để xem tệp tham chiếu:

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 để trỏ đến một kho khoá khác, hãy đảm bảo rằng bí danh đó đã cùng một 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 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 ba lần tải các thuật toán cân bằng.

Để 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 phần phụ trợ máy chủ.

Chính sách

Thư mục /policies trong proxy API chứa mọi chính sách có thể áp dụng được đí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 về chính sách

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

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

Chính sách được đính kèm dưới dạng các bước xử lý trong Luồng. Tên của chính sách được dùng để tham chiếu chính sách sẽ được thực thi như một Bước xử lý. Định dạng của một tài liệu đính kèm về chính sách: 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 Quy trình. Ví dụ:

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

Cấu hình tệp đính kèm về chính sách Elements

Luồng

ProxyEndpoint và TargetEndpoint xác định quy trình cho thông báo yêu cầu và phản hồi đang xử lý. 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 yêu cầu luồng và luồng phản hồi được chia nhỏ thành PreFlow, một hoặc nhiều thuộc tính "có điều kiện" (không bắt buộc) hoặc "đã đặt tên" và PostFlow.

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

Ngoài ra, bạn có thể thêm PostClientFlow vào ProxyEndpoint, hàm này sẽ thực thi sau được trả về ứng dụng khách yêu cầu. Chỉ có MessageLogging và chính sách Có thể đính kèm Tiện ích ghi nhật ký Google Stackdriver vào quy trình này. PostClientFlow giảm độ trễ của proxy API và cung cấp thông tin cho việc ghi nhật ký không được tính toán cho đến khi phản hồi được trả về cho ứng dụng, chẳng hạn như client.sent.start.timestamp và client.sent.end.timestamp.Luồng được sử 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 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ư.

    ...
    <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 sẽ thực thi Luồng theo trình tự sau:

Quy trình yêu cầu:

1. Luồng trước yêu cầu proxy
2. Luồng có điều kiện yêu cầu proxy (Không bắt buộc)
3. Yêu cầu proxy PostFlow
4. Luồng trước yêu cầu mục tiêu
5. Luồng có điều kiện 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. Trước luồng 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. Sau luồng phản hồi mục tiêu
4. Trước luồng 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. Luồng phản hồi proxy sau luồng
7. Phản hồi của PostClientFlow (Không bắt buộc)

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

Trái ngược với các 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 API tại thời điểm thích hợp trong quy trình, bất kể chúng xuất hiện ở đâu 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ũng được gọi là "luồng được đặt tên").

Proxy API kiểm tra điều kiện được chỉ định trong luồng có điều kiện và nếu điều kiện đáp ứng thì các bước xử lý trong quy trình 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. Câu lệnh có điều kiện Các luồng được đánh giá theo thứ tự đã xác định trong proxy API và luồng đầu tiên có điều kiện là đã 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 thông số truy vấn, tiêu đề và thông 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 chỉ định rằng nó chỉ được thực thi khi đường dẫn tài nguyên yêu cầu là /accesstoken. Bất kỳ yêu cầu đến nào có đường dẫn /accesstoken khiến luồng này được thực thi, cùng với mọi chính sách được gắn với luồng. Nếu đường dẫn yêu cầu không chứa hậu tố /accesstoken, thì luồng này không thực thi (mặc dù một luồng 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

Trình tự sắp xếp của các Luồng có điều kiện được Apigee Edge thực thi. 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 được đánh giá là true đượ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 Quy trình sau đây, mọi yêu cầu đến không bao gồm hậu tố đường dẫn /first hoặc /second sẽ khiến ThirdFlow để thực thi, 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à phép biến đổi tập lệnh, mã và BII có thể đính kèm vào Luồng bằng cách sử dụng chính sách. Các lệnh này xuất hiện trong "Tập lệnh" của API trình chỉnh sửa proxy trong giao diện người dùng quản lý.

Xem Tệp tài nguyên để biết tài nguyên.

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, đượ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ừ API proxy, với môi trường, đến 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. Các chính sách có thể tham chiếu tài nguyên được lưu trữ ở cấp môi trường trong môi trường đó. Đáp tài nguyên được lưu trữ ở cấp proxy API chỉ có thể được chính sách trong proxy API đó tham chiếu.