已合併的 API - AWS AppSync
合併的 API 和同盟合併的 API 衝突解決配置模式設定授權模式設定執行角色使用設定跨帳戶合併 API AWS RAM合併對合併 API 的其他支援合併的 API 限制建立合併的 API

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

已合併的 API

隨著 GraphQL 在組織內的使用擴展，可能會在 API ease-of-use 和 API 開發速度之間取捨。一方面，組織採AWS AppSync用 GraphQL 來簡化應用程式開發，方法是為開發人員提供彈性的 API，讓他們透過單一網路呼叫，安全地存取、操作和合併來自一或多個資料網域的資料。另一方面，組織內負責將不同資料網域合併為單一 GraphQL API 端點的團隊可能希望能夠彼此獨立建立、管理和部署 API 更新，以提高其開發速度。

為了解決這種緊張問題，AWS AppSync合併的 API 功能允許來自不同資料網域的團隊獨立建立和部署 AWS AppSync API (例如 GraphQL 結構描述、解析器、資料來源和函數)，然後將這些 API 合併為單一的合併 API。這使組織能夠維護簡單易用的跨域 API，並為不同團隊提供一種方式，這些團隊有助於該 API 快速且獨立地進行 API 更新的能力。

使用合併 API，組織可以將多個獨立來源 AWS AppSync API 的資源匯入單一AWS AppSync合併的 API 端點。為此，AWS AppSync允許您創建源代碼 API 的列表，然後將與AWS AppSync源 API（包括模式，類型，數據源，解析器和函數）關聯的所有元數據合併到新的合併 API 中。AWS AppSync

在合併期間，可能會因為來源 API 資料內容 (例如組合多個結構描述時類型命名衝突) 的不一致而發生合併衝突。對於來源 API 中沒有任何定義衝突的簡單使用案例，不需要修改來源 API 結構描述。生成的合併 API 只是從原始源 API 導入所有類型，解析器，數據源AWS AppSync和函數。對於發生衝突的複雜用例，用戶/團隊將不得不通過各種方式解決衝突。 AWS AppSync為使用者提供數種可減少合併衝突的工具和範例。

在中設定的後續合併AWS AppSync會將來源 API 中所做的變更傳播至關聯的合併 API。

合併的 API 和同盟

GraphQL 社群中有許多解決方案和模式，可用於結合 GraphQL 結構描述，並透過共用圖形實現團隊協同作業。 AWS AppSync合併的 API 採用構建時間方法來構成結構描述，其中源 API 合併為單獨的合併 API。另一種方法是跨多個源 API 或子圖層運行時路由器。在這種方法中，路由器會接收要求、參考它維護為中繼資料的組合結構描述、建構要求計劃，然後將要求元素散佈至其基礎子圖形/伺服器。下表將合AWS AppSync併的 API 建置階段方法與 GraphQL 結構描述構成的路由器型執行階段方法進行比較：

Feature AppSync Merged API Router-based solutions
Sub-graphs managed independently Yes Yes
Sub-graphs addressable independently Yes Yes
Automated schema composition Yes Yes
Automated conflict detection Yes Yes
Conflict resolution via schema directives Yes Yes
Supported sub-graph servers AWS AppSync* Varies
Network complexity Single, merged API means no extra network hops. Multi-layer architecture requires query planning and delegation, sub-query parsing and serialization/deserialization, and reference resolvers in sub-graphs to perform joins.
Observability support Built-in monitoring, logging, and tracing. A single, Merged API server means simplified debugging. Build-your-own observability across router and all associated sub-graph servers. Complex debugging across distributed system.
Authorization support Built in support for multiple authorization modes. Build-your-own authorization rules.
Cross account security Built-in support for cross-AWS cloud account associations. Build-your-own security model.
Subscriptions support Yes No

* AWS AppSync 合併的 API 只能與AWS AppSync來源 API 建立關聯。如果您需要跨越AWS AppSync和非AWS AppSync子圖形的結構描述構成支援，您可以將一或多個 AWS AppSync GraphQL 和/或合併的API 連接到路由器型解決方案中。例如，請參閱參考部落格，瞭解如AWS AppSync何使用路由器架構搭配阿波羅聯合 v2：阿波羅 Graph QL 聯合使用. AWS AppSync

合併的 API 衝突解決

發生合併衝突時，會為使用者AWS AppSync提供數種工具和範例，以協助疑難排解問題。

合併的 API 架構指令

AWS AppSync引入了幾個 GraphQL 指令，這些指令可用於減少或解決來源 API 之間的衝突：

  • @canonical：此指令設置具有相似名稱和數據的類型/字段的優先級。如果兩個或多個源 API 具有相同的 GraphQL 類型或字段，則其中一個 API 可以將其類型或字段註釋為標準，這些 API 將在合併期間優先級。合併時，會忽略其他來源 API 中未使用此指示詞註解的衝突類型/欄位。

  • @hidden：此指令封裝某些類型/字段以將其從合併過程中刪除。團隊可能想要移除或隱藏來源 API 中的特定類型或作業，以便只有內部用戶端可以存取特定類型的資料。附加此指令後，類型或欄位不會合併到合併的 API 中。

  • @renamed：此指令更改類型/字段的名稱以減少命名衝突。在某些情況下，不同的 API 具有相同的類型或字段名稱。但是，它們都需要在合併的模式中可用。將它們全部包含在合併的 API 中的一種簡單方法是將字段重命名為類似但不同的字段。

要顯示實用程序模式指令提供，請考慮以下示例：

在此範例中，假設我們想要合併兩個來源 API。我們給出了兩個模式來創建和檢索帖子（例如，評論部分或社交媒體帖子）。假設類型和字段非常相似，在合併操作期間發生衝突的可能性很高。下面的片段顯示了每個模式的類型和字段。

第一個文件，稱為源 1.GraphQL，是一個 Gra phQL 模式，允許用戶使用突變創建。Posts putPost每個都Post包含一個標題和一個 ID。ID 用於引用User，或海報的信息（電子郵件和地址），以及Message，或有效負載（內容）。User類型會以 @canonical 標籤加上註解。

# This snippet represents a file called Source1.graphql

type Mutation {
    putPost(id: ID!, title: String!): Post
}

type Post {
    id: ID!
    title: String!
}

type Message {
   id: ID!
   content: String
}

type User @canonical {
   id: ID!
   email: String!
   address: String!
}

type Query {
    singlePost(id: ID!): Post
    getMessage(id: ID!): Message
}

第二個文件，稱為源 2. 圖形 SQL，是一個 GraphQL 模式，它做非常相似的事情來源 1.GraphQL。但是，請注意，每種類型的欄位都不同。合併這兩個結構描述時，會因為這些差異而產生合併衝突。

還要注意源 2.GraphQL 還包含幾個指令來減少這些衝突。該Post類型用 @hidden 標籤註釋，以便在合併操作期間混淆自己。Message類型會以 @renamed 標籤註解，以便ChatMessage在與其他類型發生命名衝突時將Message類型名稱修改為。

# This snippet represents a file called Source2.graphql

type Post @hidden  {
    id: ID!
    title: String!
    internalSecret: String!
}

type Message @renamed(to: "ChatMessage") {
   id: ID!
   chatId: ID!
   from: User!
   to: User!
}

# Stub user so that we can link the canonical definition from Source1
type User {
   id: ID!
}

type Query {
    getPost(id: ID!): Post
    getMessage(id: ID!): Message @renamed(to: "getChatMessage")
}

當合併發生時，結果將產生文MergedSchema.graphql件：

# This snippet represents a file called MergedSchema.graphql

type Mutation {
    putPost(id: ID!, title: String!): Post
}

# Post from Source2 was hidden so only uses the Source1 definition. 
type Post {
    id: ID!
    title: String!
}

# Renamed from Message to resolve the conflict
type ChatMessage {
   id: ID!
   chatId: ID!
   from: User!
   to: User!
}

type Message {
   id: ID!
   content: String
}

# Canonical definition from Source1
type User {
   id: ID!
   email: String!
   address: String!
}

type Query {
    singlePost(id: ID!): Post
    getMessage(id: ID!): Message
    
    # Renamed from getMessage
    getChatMessage(id: ID!): ChatMessage
}

合併中發生了幾件事情：

  • 由於 @canonical 註釋，源 1.GraphQL 中的User類型優先於來源 2. 圖形 QL 的User優先級。

  • 來自源 1.GraphQL 的Message類型已包含在合併中。但是，來Message自源 2.GraphQL 存在命名衝突。由於其 @renamed 註釋，它也包含在合併中，但具有替代名稱ChatMessage。

  • 來自源 1.GraphQL 的Post類型已包含在內，但來自源 2. 圖形 QL 的Post類型不是。通常情況下，這種類型會發生衝突，但是由於 Source2.GraphQL 中的Post類型具有 @hidden 註釋，因此其數據被模糊化並且不包含在合併中。這會導致沒有衝突。

  • Query類型已更新，以包含兩個檔案中的內容。但是，由於該指令的GetChatMessage原因，有一個GetMessage查詢被重新命名。這解決了具有相同名稱的兩個查詢之間的命名衝突。

還有沒有指令被添加到衝突的類型的情況。在這裡，合併的類型將包括該類型的所有源定義中所有字段的聯集。例如，請考量下列範例：

這個結構描述，稱為源 1.GraphQL，允許創建和檢索。Posts組態與前面的範例類似，但資訊較少。

# This snippet represents a file called Source1.graphql

type Mutation {
    putPost(id: ID!, title: String!): Post
}

type Post  {
    id: ID!
    title: String!
}

type Query {
    getPost(id: ID!): Post
}

這個模式稱為 Source2.GraphQL，允許創建和檢索Reviews（例如，電影評分或餐廳評論）。 Reviews與相同Post的 ID 值相關聯。它們共同包含完整評論帖子的標題，帖子 ID 和有效負載消息。

合併時，兩Post種類型之間會發生衝突。因為沒有註釋可以解決此問題，因此預設行為是對衝突的類型執行聯集操作。

# This snippet represents a file called Source2.graphql

type Mutation {
    putReview(id: ID!, postId: ID!, comment: String!): Review
}

type Post  {
    id: ID!
    reviews: [Review]
}

type Review {
   id: ID!
   postId: ID!
   comment: String!
}

type Query {
    getReview(id: ID!): Review
}

當合併發生時，結果將產生文MergedSchema.graphql件：

# This snippet represents a file called MergedSchema.graphql

type Mutation {
    putReview(id: ID!, postId: ID!, comment: String!): Review
    putPost(id: ID!, title: String!): Post
}

type Post  {
    id: ID!
    title: String!
    reviews: [Review]
}

type Review {
   id: ID!
   postId: ID!
   comment: String!
}

type Query {
    getPost(id: ID!): Post
    getReview(id: ID!): Review
}

合併中發生了幾件事情：

  • 該Mutation類型沒有衝突並被合併。

  • Post類型字段通過聯集操作進行組合。請注意兩者之間的聯集如何產生單個 idtitle，a 和單個reviews。

  • 該Review類型沒有衝突並被合併。

  • 該Query類型沒有衝突並被合併。

管理共用類型的解析器

在上述範例中，請考慮來源 1.GraphQL 已在上設定單位解析器的情況Query.getPost，該解析器使用名為的 DynamoDB 資料來源。PostDatasource這個Post解析器將返回一個類型title的id和。現在，考慮源 2.GraphQL 已經配置了一個管道解析器，它運行兩個函數。Post.reviews Function1具有附加的None資料來源以執行自訂授權檢查。 Function2具有附加的 DynamoDB 資料來源可供查詢資料表reviews。

query GetPostQuery {
    getPost(id: "1") {
        id,
        title,
        reviews
    }
}

當用戶端對合併的 API 端點執行上述查詢時，AWS AppSync服務會先執行來源的單位解析程式Source1，然後Query.getPost從 DynamoDB 呼叫PostDatasource並傳回資料。然後，它會執行Post.reviews管線解析程式，其中Function1執行自訂授權邏輯，並Function2傳回中id找到的檢閱。$context.source服務會以單一 GraphQL 執行的方式處理要求，而且這個簡單的要求只需要單一要求權杖。

管理共用類型的解析程式衝突

考慮下面的情況下，我們還實現了一個解析器，以便Query.getPost在一次超出字段解析器中提供多個字段。Source2源 1.GraphQL 可能看起來像這樣：

# This snippet represents a file called Source1.graphql

type Post  {
    id: ID!
    title: String!
    date: AWSDateTime!
}

type Query {
    getPost(id: ID!): Post
}

源 2. 圖形 QL 可能看起來像這樣：

# This snippet represents a file called Source2.graphql

type Post  {
  id: ID!
  content: String!
  contentHash: String! 
  author: String! 
}

type Query {
    getPost(id: ID!): Post
}

嘗試合併這兩個結構描述將產生合併錯誤，因為合AWS AppSync併的 API 不允許將多個源解析器附加到同一個字段。為了解決這種衝突，您可以實現一個字段解析器模式，該模式需要 S ource2.GraphQL 添加一個單獨的類型，該類型將定義它擁有的類型的字段。Post在下面的例子中，我們添加了一個名為的類型PostInfo，其中包含將由 Source 2.GraphQL 解析的內容和作者字段。S@@ ource1.graphQL 將實現附加到的解析器Query.getPost，而 S ource2.GraphQL 現在將附加一個解析器，以確保可以成功檢索所有數據：Post.postInfo

type Post  {
  id: ID!
  postInfo: PostInfo
}

type PostInfo {
   content: String!
   contentHash: String!
   author: String!
}

type Query {
    getPost(id: ID!): Post
}

雖然解決此類衝突需要重寫源 API 結構描述，並且可能客戶更改其查詢，但這種方法的優點是，合併解析器的所有權在於跨來源團隊保持清晰。

配置模式

雙方負責配置結構描述以創建合併的 API：

  • 合併的 API 擁有者-合併的 API 擁有者必須配置合併 API 的授權邏輯和進階設定，例如記錄、追蹤、快取和 WAF 支援。

  • 關聯的來源 API 擁有者-相關聯的 API 擁有者必須設定組成合併 API 的結構描述、解析器和資料來源。

由於合併 API 的結構描述是從關聯來源 API 的結構描述建立的，因此它是唯讀的。這表示您必須在來源 API 中啟動結構描述的變更。在AWS AppSync主控台中，您可以使用 [結構描述] 視窗上方的下拉式清單，在 [已合併的結構描述] 和 [已合併 API] 中包含的來源 API 的個別結構描述之間切換。

設定授權模式

多種授權模式可用於保護您的合併 API。若要深入瞭解中的授權模式AWS AppSync，請參閱授權和驗證。

下列授權模式可與合併的 API 搭配使用：

  • API 密鑰：最簡單的授權策略。所有請求都必須在請x-api-key求標題下包含一個 API 密鑰。過期的 API 金鑰會在到期日期後保留 60 天。

  • AWSIdentity and Access Management (IAM)：AWSIAM 授權策略會授權所有 sigv4 簽署的請求。

  • Amazon Cognito 使用者集區：透過 Amazon Cognito 使用者集區授權您的使用者，以實現更精細的控制。

  • AWSLambda 授權者：一種無伺服器函數，可讓您使用自訂邏輯對 AWS AppSync API 進行驗證和授權存取。

  • OpenID Connect：此授權類型強制執行 OIDC 兼容服務提供的 OpenID 連接（OIDC）令牌。您的應用程式可以運用由 OIDC 提供者定義的使用者與權限來控制存取權限。

合併 API 的授權模式由合併的 API 擁有者設定。在合併作業時，「已合併的 API」必須包含在來源 API 上設定的主要授權模式，作為其本身的主要授權模式或次要授權模式。否則，它將不兼容，並且合併操作將失敗並發生衝突。在源 API 中使用多重身份驗證指令時，合併過程能夠將這些指令自動合併到統一端點中。在源 API 的主授權模式與合併 API 的主授權模式不匹配的情況下，它將自動添加這些身份驗證指令，以確保源 API 中類型的授權模式一致。

設定執行角色

建立合併的 API 時，您需要定義服務角色。AWS服務角色是 I AWS dentity and Access Management (IAM) 角色，AWS服務會用來代表您執行工作。

在這種情況下，您的合併 API 必須運行解析器，以訪問源 API 中配置的數據源中的數據。必要的服務角色是mergedApiExecutionRole，它必須具有明確存取權，才能透過 appsync:SourceGraphQL IAM 許可在合併的 API 中包含的來源 API 上執行請求。在 GraphQL 要求執行期間，AWS AppSync服務會擔任此服務角色，並授權角色執行appsync:SourceGraphQL動作。

AWS AppSync支援在請求中的特定頂層欄位上允許或拒絕此權限，例如 IAM 授權模式對 IAM API 的運作方式。對於 non-top-level欄位，AWS AppSync需要您定義來源 API ARN 本身的權限。為了限制對合併 API 中特定 non-top-level 欄位的存取，我們建議您在 Lambda 中實作自訂邏輯，或使用 @hidden 指示詞在合併 API 中隱藏來源 API 欄位。如果您想要允許角色執行來源 API 中的所有資料作業，您可以在下方新增政策。請注意，第一個資源項目允許訪問所有頂級字段，第二個條目涵蓋對源 API 資源本身授權的子解析器：

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow", 
        "Action": [ "appsync:SourceGraphQL"], 
        "Resource": [ 
            "arn:aws:appsync:us-west-2:123456789012:apis/YourSourceGraphQLApiId/*", 
            "arn:aws:appsync:us-west-2:123456789012:apis/YourSourceGraphQLApiId"] 
    }] 
}

如果您想限制只有特定頂層欄位的存取權限，您可以使用如下策略：

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow", 
        "Action": [ "appsync:SourceGraphQL"], 
        "Resource": [ 
            "arn:aws:appsync:us-west-2:123456789012:apis/YourSourceGraphQLApiId/types/Query/fields/<Field-1>",
            "arn:aws:appsync:us-west-2:123456789012:apis/YourSourceGraphQLApiId"] 
    }] 
}

您也可以使用AWS AppSync主控台 API 建立精靈來產生服務角色，以允許合併的 API 存取與合併 API 位於相同帳戶的來源 API 中設定的資源。如果您的來源 API 與合併的 API 不在相同的帳戶中，您必須先使用 AWS Resource Access Manager (AWS RAM) 共用資源。

使用設定跨帳戶合併 API AWS RAM

建立合併的 API 時，您可以選擇性地關聯已透過 AWS Resource Access Manager (AWS RAM) 共用的其他帳戶的來源 API。 AWS RAM協助您跨AWS帳戶、組織或組織單位 (OU) 內，以及 IAM 角色和使用者安全地共用資源。

AWS AppSync與AWS RAM整合，以支援透過單一合併 API 跨多個帳戶設定和存取來源 API。 AWS RAM可讓您建立資源共用或資源容器，以及將為每個資源共用的權限集。您可以將 AWS AppSync API 新增至中的資源共用AWS RAM。在資源共用中，AWS AppSync提供三個可與 RAM 中的 AWS AppSync API 相關聯的不同權限集：

  1. AWSRAMPermissionAppSyncSourceApiOperationAccess：如果未指定其他權限，AWS RAM則在共享 AWS AppSync API 時添加的默認權限集。此權限集用於與合併的 AWS AppSync API 擁有者共用來源 API。此權限集包括來源 API appsync:AssociateMergedGraphqlApi 的權限，以及在執行階段存取來源 API 資源所需的appsync:SourceGraphQL權限。

  2. AWSRAMPermissionAppSyncMergedApiOperationAccess：與來源 API 擁有者共用合併的 API 時，應設定此權限集。此權限集將使來源 API 能夠設定合併的 API，包括將目標主體擁有的任何來源 API 與合併 API 相關聯，以及讀取和更新合併 API 的來源 API 關聯。

  3. AWSRAMPermissionAppSyncAllowSourceGraphQLAccess：此權限集允許appsync:SourceGraphQL權限與 AWS AppSync API 搭配使用。它旨在用於與合併的 API 所有者共享源 API。與為來源 API 作業存取設定的預設權限不同，此權限集僅包含執行階段權限appsync:SourceGraphQL。如果使用者選擇將「已合併的 API」作業存取權共用給來源 API 擁有者，他們還需要將來源 API 的此權限共用給「已合併的 API」擁有者，才能透過「合併的 API」端點擁有執行階段存取權。

AWS AppSync也支援客戶管理的權限。當其中一個提供的AWS受管理權限無法運作時，您可以建立自己的客戶管理權限。客戶管理的權限是您編寫和維護的受管理權限，方法是精確指定可以在哪些情況下與使用共用AWS RAM資源執行的動作。 AWS AppSync可讓您在建立自己的權限時從下列動作中進行選擇：

  1. appsync:AssociateSourceGraphqlApi

  2. appsync:AssociateMergedGraphqlApi

  3. appsync:GetSourceApiAssociation

  4. appsync:UpdateSourceApiAssociation

  5. appsync:StartSchemaMerge

  6. appsync:ListTypesByAssociation

  7. appsync:SourceGraphQL

在中正確共用來源 API 或合併 API 之AWS RAM後，如有必要，資源共用邀請已被接受，當您在合併的 API 上建立或更新來源 API 關聯時，該邀請將會顯示在AWS AppSync主控台中。您也可以透過呼叫所提供的ListGraphqlApis作業AWS AppSync並使用擁AWS RAM有OTHER_ACCOUNTS者篩選器，列出所有使用您帳戶共用的 AWS AppSync API，而不論權限設定為何。

注意

透過AWS RAM共用時，呼叫者AWS RAM必須擁有對正在共用的任何 API 執行appsync:PutResourcePolicy動作的權限。

合併

管理合併

合併的 API 旨在支持統一AWS AppSync端點上的團隊協作。團隊可以在後端獨立發展自己的獨立來源 GraphQL API，同時該AWS AppSync服務將資源整合到單一合併 API 端點中，以減少協同作業的摩擦並縮短開發前置時間。

自動合併

您可以將與合AWS AppSync併 API 相關聯的來源 API 設定為在來源 API 進行任何變更後，自動合併 (自動合併) 到合併的 API。這樣可確保來自來源 API 的變更始終在背景傳播到合併的 API 端點。只要來源 API 結構描述中的任何變更不會與合併 API 中的現有定義產生合併衝突，就會在「合併的 API」中更新。如果來源 API 中的更新正在更新解析器、資料來源或函數，則匯入的資源也會更新。引入無法自動解決 (自動解決) 的新衝突時，由於合併作業期間發生不支援的衝突，導致「已合併的 API 結構描述更新」遭到拒絕。對於每個狀態為的來源 API 關聯，主控台中都會顯示錯誤訊息MERGE_FAILED。您還可以通過使用 AWS SDK 調用給定源 API 關聯的GetSourceApiAssociation操作或使用 AWS CLI 來檢查錯誤消息，如下所示：

aws appsync get-source-api-association --merged-api-identifier <Merged API ARN> --association-id <SourceApiAssociation id>

這將產生以下格式的結果：

{
    "sourceApiAssociation": {
        "associationId": "<association id>",
        "associationArn": "<association arn>",
        "sourceApiId": "<source api id>",
        "sourceApiArn": "<source api arn>",
        "mergedApiArn": "<merged api arn>",
        "mergedApiId": "<merged api id>",
        "sourceApiAssociationConfig": {
            "mergeType": "MANUAL_MERGE"
        },
        "sourceApiAssociationStatus": "MERGE_FAILED",
        "sourceApiAssociationStatusDetail": "Unable to resolve conflict on object with name title: Merging is not supported for fields with different types."
    }
}

手動合併

來源 API 的預設設定為手動合併。若要合併自合併 API 上次更新後在來源 API 中發生的任何變更，來源 API 擁有者可以從AWS AppSync主控台或透過 AWS SDK 和 AWS CLI 中可用的StartSchemaMerge作業叫用手動合併。

對合併 API 的其他支援

設定訂閱

與以路由器為基礎的 GraphQL 結構描述構成方法不同，AWS AppSync合併的 API 提供 GraphQL 訂閱的內建支援。在您關聯的來源 API 中定義的所有訂閱作業都會自動合併並在您的合併 API 中運作，而無需修改。若要深入瞭解如何透過無伺服器 WebSockets 連線AWS AppSync支援訂閱，請參閱即時資料。

配置可觀測性

AWS AppSync合併的 API 透過 Amazon 提供內建的記錄、監控和指標 CloudWatch。 AWS AppSync還提供內置支持跟踪通過 AWS X-Ray.

設定自訂網域

AWS AppSync合併的 API 提供內建支援，可將自訂網域與合併 API 的 GraphQL 和即時端點搭配使用。

配置緩存

AWS AppSync合併的 API 提供內建支援，可選擇快取要求層級和/或解析程式層級的回應，以及回應壓縮。若要深入瞭解，請參閱快取和壓縮。

設定私有 API

AWS AppSync合併的 API 為私有 API 提供內建支援，可限制對來自您可設定之 VPC 端點的流量存取合併 API 的 GraphQL 和即時端點的流量。

設定防火牆規則

AWS AppSync合併的 API 提供的內建支援AWS WAF，可讓您透過定義 Web 應用程式防火牆規則來保護 API。

設定稽核記錄

AWS AppSync合併的 API 提供內建支援 AWS CloudTrail，可讓您設定和管理稽核記錄。

合併的 API 限制

開發合併的 API 時，請注意以下規則：

  1. 合併的 API 不能是另一個合併 API 的來源 API。

  2. 來源 API 無法與一個以上的合併 API 相關聯。

  3. 「合併的 API 結構描述」文件的預設大小限制為 10 MB。

  4. 可與合併 API 相關聯的來源 API 預設數量為 10。不過，如果您在合併的 API 中需要 10 個以上的來源 API，則可以要求提高限制。

建立合併的 API

在主控台中建立合併的 API

  1. 登入 AWS Management Console 並開啟 AWS AppSync主控台。

    1. 在儀表板中，選擇「建立 API」。

  2. 選擇合併的 API，然後選擇下一步。

  3. 在「指定 API 詳細資訊」頁面中，輸入下列資訊：

    1. 在「API 詳細資訊」下，輸入下列資訊：

      1. 指定合併的 API 名稱。此欄位是為 GraphQL API 加上標籤的一種方式，以便於將其與其他 GraphQL API 區分開來。

      2. 指定聯絡人詳細資料。此欄位為選擇性欄位，並將名稱或群組附加至 GraphQL API。它不會連結至其他資源或由其他資源產生，而且運作方式與 API 名稱欄位非常相似。

    2. 在「服務角色」下，您必須將 IAM 執行角色附加到合併的 API，AWS AppSync以便在執行時期安全地匯入和使用您的資源。您可以選擇建立和使用新的服務角色，這將允許您指定AWS AppSync將使用的策略和資源。您也可以選擇使用現有的服務角色，然後從下拉式清單中選取角色，以匯入現有的 IAM 角色。

    3. 在私人 API 配置下，您可以選擇啟用私有 API 功能。請注意，建立合併的 API 後，無法變更此選項。如需有關私有 API 的詳細資訊，請參閱使用AWS AppSync私有 API。

      完成後，請選擇 [下一步]。

  4. 接下來，您必須新增 GraphQL API，這些 API 將用作合併 API 的基礎。在 [選取來源 API] 頁面中，輸入下列資訊：

    1. 在AWS帳戶表格中的 API 中，選擇「新增來源 API」。在 GraphQL API 清單中，每個項目都會包含下列資料：

      1. 名稱：圖 GraphQL API 的 API 名稱欄位。

      2. API 識別碼：圖 GraphQL API 的唯一識別碼值。

      3. 主要驗證模式：GraphQL API 的預設授權模式。如需中授權模式的詳細資訊AWS AppSync，請參閱授權與驗證。

      4. 額外的驗證模式：在 GraphQL API 中設定的次要授權模式。

      5. 選取 API 名稱欄位旁邊的核取方塊，選擇您要在合併 API 中使用的 API。然後，選擇添加源 API。選取的 GraphQL API 會顯示在您AWS帳戶表格中的 API 中。

    2. 在來自其他AWS帳戶的 API 表格中，選擇新增來源 API。此列表中的 GraphQL API 來自通過AWS Resource Access Manager（AWS RAM）將其資源共享給您的其他帳戶。在此表格中選取 GraphQL API 的程序與上一節中的程序相同。如需透過共用資源的詳細資訊AWS RAM，請參閱什麼是AWS Resource Access Manager? 。

      完成後，請選擇 [下一步]。

    3. 添加您的主要身份驗證模式。如需詳細資訊，請參閱授權和驗證。選擇下一步。

    4. 檢閱您的輸入，然後選擇「建立 API」。