単純な親／子関係の構文

多くの場合、ルートリソースと包含リソース間の関係は単純な親／子関係です。この例としては、次のようなものがあります。

  • アクティビティとその備考・経緯
  • クレームとその違反記録

単純な親／子関係の要求包含を使用している場合、JSON の構造は次のようになります。

{
  "data" : {
    "attributes": {
      ...
    }
  },
  "included": {
    "<resourceType>": [
      {
        "attributes": {
          ...
        },
        "method": "post",
        "uri": "/../this/..."
      }
    ]
  }
}

data セクション

data セクションには、attributes などのルートリソースに関する情報が含まれています。（パッチの場合は、data セクションにルートリソースのチェックサム値を含めることもできます。）

included セクション

included セクションは、包含リソースの 1 つ以上のサブセクションで構成されます。各サブセクションはリソースタイプ名から始まります。その後、該当のタイプのリソースを 1 つ以上指定できます。各リソースについて、以下を指定します。

  • リソースの attributes
  • リソースを作成または変更するための method と uri

method フィールドと uri フィールド

要求包含では、1 つのエンドポイントに対して 1 つの呼び出しを指定します。ただし、内部では、クラウド API が複数のエンドポイントを使用してその呼び出しを実行します。すべての包含リソースについて、そのリソースに関連する操作と URI を指定する必要があります。

例えば、クレームと備考・経緯を作成するために POST /claims 呼び出しを記述しているとします。この備考・経緯が included リソースになります。included セクションには、次のようなコードが含まれます。

"included": {
  "Note": [
    {
      "attributes": {
          ...
      },
      "method": "post",
      "uri": "/claim/v1/claims/this/notes"
    }
  ]
}

このコードは、備考・経緯を作成するために、POST /claim/v1/claims/{claimId}/notes エンドポイントを使用することを指定しています。

URI は「/claim/v1」などの API 名から始めます。

ここではルートリソースの ID も指定する必要があります。ルートリソースと包含リソースを同時に作成している場合は、ルートリソースにはまだ ID がありません。したがって、ルートリソースの ID を表すためにキーワード this を URI に使用します。

単純な親／子関係の要求包含の例

次のペイロードは、クレームとクレームの備考・経緯の作成例です。このペイロードでは、番号が「FNOL-POLICY」の既存の保険契約があることを前提としています。保険契約の作成の詳細については、事故受付の実行を参照してください。

POST http://localhost:8080/cc/rest/claim/v1/claims

{
  "data" : {
    "attributes": {
      "lossDate": "2020-02-01T07:00:00.000Z",
      "policyNumber": "FNOL-POLICY"
	}
  },
  "included": {
    "Note": [
      {
        "attributes": {
            "subject": "Initial phone call",
            "body": "Initial phone call with claimant"
        },
        "method": "post",
        "uri": "/claim/v1/claims/this/notes"
      }
    ]
  }
}