REST 演習2：子リソースの取得と作成・更新・エラー

この演習の結論

• 親と子の取得には、「子の URL で取る」「expand で埋め込む」「fields=親の項目;子:項目 で必要な項目だけ取る」の 3 通りがあります。Version 3 以降は、子が配列ではなく items・hasMore を持つコレクションの形で返ります。
• 作成（POST）・更新（PATCH）・削除（DELETE）は、JSON を Content-Type: application/json で送ります。このモックは「必須項目 → 値の検証 → 業務ルール（重複など）」の順に検証し、何も保存しません。成功しても請求書は増えず、取得もできません。
• エラーの形は Version で変わります。Version 1〜3 はテキスト、Version 4 以降は o:errorCode・o:errorPath を持つ JSON で、原因の項目を機械的に読めます。

この演習で身につくこと

• 請求書の links を読み、子リソース（明細）を取得できる。expand と fields を使い分けられる
• finder で 1 件を探し、links の self から URL を得られる
• POST で請求書を作り、必須項目の不足・重複・業務ルールのエラーを読んで直せる
• PATCH で更新できる項目とできない項目、DELETE できる条件を確認できる
• Version 1 と Version 4 のエラー応答の違いを説明し、o:errorPath から原因の項目を特定できる

検索・絞り込み・ページングは REST 演習1 で扱いました。この演習は、その続きです。仕組みの説明は REST API 応用 と REST API の基本 を参照してください。

前提・準備（Fusion 環境あり／なし）

シナリオ（架空）

サンプル商事株式会社の AP 担当者が、請求書とその明細を確認し、新しい請求書を登録し、説明欄を直し、入力ミスの請求書を削除します。途中で返ってくるエラーから、原因を特定します。

環境なしルート（この演習の標準）

REST 演習1 と同じ準備です（bash、curl、jq、練習用モック API）。ターミナルを使えない場合は、練習用 API プレイグラウンド の「1 件取得」「明細（子リソース）」「親と子を一緒に取得（expand）」「作成（POST）」「更新（PATCH）」「削除（DELETE）」から始められます。

準備（最初に 1 回。演習1 で済ませていれば不要）

export BASE="https://<このサイトのURL>/api/mock/fscmRestApi/resources/11.13.18.05"

この演習で追加で使う curl のオプションは次のとおりです。

オプション	意味
-X POST・-X PATCH・-X DELETE	HTTP メソッドを指定する
-H 'Content-Type: application/json'	本文が JSON であることを伝える（-d だけでは form 形式で送られます）
-d @new-invoice.json	ファイルの内容を本文として送る
-D headers.txt	応答ヘッダーをファイルに保存する
-o body.json	応答本文をファイルに保存する

Fusion 環境ありルート

同じ手順を、実機の請求書（invoices）で試せます。ただし、作成・更新・削除は実際にデータを変更します。必ずテスト環境で、演習用の請求書番号を使ってください。

• BASE と -u の読み替えは、演習1 と同じです（認証情報は環境変数から読みます）
• 請求書を作成・更新できるユーザーが必要です（画面で請求書を作成できるロールが目安です。例：Accounts Payable Specialist）。REST の呼び出しに追加で必要な権限は、公式の該当ページに書かれていません。セキュリティ担当に確認してください（認証・認可）
• 作成の必須項目と、仕入先・サイト・営業単位などの値は、環境ごとに異なります。「実機との違い」の表を読んでから試してください

手順

ステップ1 請求書 1 件と links を見る

一覧にも 1 件の応答にも、links が付いています。請求書 300100001 の links を見ます。

curl -s -u learner:welcome1 "$BASE/invoices/300100001" | jq -c '.links[] | {rel, name, href}'

実行結果

{"rel":"self","name":"invoices","href":"https://<このサイトのURL>/api/mock/fscmRestApi/resources/11.13.18.05/invoices/300100001"}
{"rel":"canonical","name":"invoices","href":"https://<このサイトのURL>/api/mock/fscmRestApi/resources/11.13.18.05/invoices/300100001"}
{"rel":"child","name":"invoiceLines","href":"https://<このサイトのURL>/api/mock/fscmRestApi/resources/11.13.18.05/invoices/300100001/child/invoiceLines"}

• self：この請求書自身の URL です。更新（PATCH）と削除（DELETE）は、ここに送ります
• child：子リソース（明細 invoiceLines）の URL です

実機では URL を自分で組み立てない

このモックの URL のキーは、請求書が InvoiceId、明細が LineNumber です。実機は違います。公式ドキュメントでは、請求書の URL のキー（invoicesUniqID）を「複合キーのハッシュ値」と説明し、クライアントが作らず、コレクションを検索して得るものとしています。実機では必ず、links の href をたどってください。

ステップ2 明細（子リソース）を取る

方法1：子の URL を直接呼ぶ。 明細だけが欲しいときの方法です。子のコレクションにも limit・offset・hasMore があります。

curl -s -u learner:welcome1 "$BASE/invoices/300100001/child/invoiceLines?onlyData=true" \
  | jq -c '{count, hasMore}, (.items[] | [.LineNumber, .LineType, .LineAmount, .Description])'

実行結果

{"count":2,"hasMore":false}
[1,"Item",480000,"コピー用紙・トナー"]
[2,"Freight",5000,"配送料"]

方法2：expand で埋め込む。 親の応答に子を含めます。REST-Framework-Version で、子の形が変わります。

for V in 1 3; do
  curl -s -u learner:welcome1 -H "REST-Framework-Version: $V" "$BASE/invoices/300100001?expand=invoiceLines&onlyData=true" \
    | jq -c --arg v "$V" '{version: $v, invoiceLines: (.invoiceLines | if type == "array" then "array(\(length))" else "object(\(keys | join(",")))" end)}'
done

実行結果

{"version":"1","invoiceLines":"array(2)"}
{"version":"3","invoiceLines":"object(count,hasMore,items,limit,links,offset)"}

Version 1〜2 は子が配列、Version 3 以降は items・hasMore などを持つコレクションです（公式ドキュメントの説明どおり）。Version 3 の形なら、子の件数が多いときに hasMore で続きがあるか判断できます。

方法3：fields で必要な項目だけ取る。 fields=親の項目;子:項目 の形で、親と子の両方を絞ります。

curl -s -u learner:welcome1 -H 'REST-Framework-Version: 3' "$BASE/invoices?limit=2&orderBy=InvoiceId&onlyData=true&fields=InvoiceId,InvoiceNumber;invoiceLines:LineNumber,LineType,LineAmount" \
  | jq -c '.items[] | {InvoiceId, InvoiceNumber, lines: [.invoiceLines.items[] | [.LineNumber, .LineType, .LineAmount]]}'

実行結果

{"InvoiceId":300100001,"InvoiceNumber":"SMP-0001","lines":[[1,"Item",480000],[2,"Freight",5000]]}
{"InvoiceId":300100002,"InvoiceNumber":"1001","lines":[[1,"Item",64800]]}

一覧で 2 件分の親と子を、1 回のリクエストで取れました。fields と expand を一緒に指定すると、fields だけが有効になります（公式ドキュメントの説明どおり）。

ステップ3 finder で 1 件を探す

finder=PrimaryKey;InvoiceId=… は、主キーで 1 件を探す定義済みの検索です（公式の invoices の finder もこの名前です）。結果の links から self を取り出すと、その請求書の URL が得られます。

curl -s -u learner:welcome1 "$BASE/invoices?finder=PrimaryKey;InvoiceId=300100001&onlyData=true&fields=InvoiceId,InvoiceNumber,Supplier" \
  | jq -c '{count, hasMore, items}'

curl -s -u learner:welcome1 "$BASE/invoices?finder=PrimaryKey;InvoiceId=300100001&fields=InvoiceId" \
  | jq -r '.items[0].links[] | select(.rel == "self") | .href'

実行結果

{"count":1,"hasMore":false,"items":[{"InvoiceId":300100001,"InvoiceNumber":"SMP-0001","Supplier":"サンプル商事株式会社"}]}
https://<このサイトのURL>/api/mock/fscmRestApi/resources/11.13.18.05/invoices/300100001

q=InvoiceId=300100001（Version 1）でも同じ請求書を探せます。実機では、この「検索して self をたどる」手順が、1 件の URL を得る正しい方法です。

ステップ4 請求書を作成する（POST）

必須項目が足りない最小の本文から始めて、エラーを読みながら直します。本文は new-invoice.json に書きます。

cat > new-invoice.json <<'EOF'
{
  "InvoiceNumber": "SMP-0007",
  "InvoiceCurrency": "JPY"
}
EOF

curl -s -u learner:welcome1 -X POST "$BASE/invoices" \
  -H 'Content-Type: application/json' -d @new-invoice.json -w '\nHTTP %{http_code}\n'

実行結果

The attribute BusinessUnit is required.
The attribute Supplier is required.
The attribute SupplierSite is required.
The attribute InvoiceAmount is required.
The attribute InvoiceDate is required.
HTTP 400

足りない必須項目が、まとめて返ります。すべて足して、明細も一緒に送ります（親の作成時に invoiceLines を渡せます）。

cat > new-invoice.json <<'EOF'
{
  "InvoiceNumber": "SMP-0007",
  "InvoiceCurrency": "JPY",
  "InvoiceAmount": 330000,
  "InvoiceDate": "2026-10-01",
  "BusinessUnit": "JP01 Business Unit",
  "Supplier": "サンプル商事株式会社",
  "SupplierSite": "TOKYO",
  "Description": "10月分 コピー用紙",
  "invoiceLines": [
    { "LineNumber": 1, "LineType": "Item", "LineAmount": 300000 },
    { "LineNumber": 2, "LineType": "Freight", "LineAmount": 30000 }
  ]
}
EOF

curl -s -u learner:welcome1 -X POST "$BASE/invoices" \
  -H 'Content-Type: application/json' -d @new-invoice.json \
  -D headers.txt -o body.json -w 'HTTP %{http_code}\n'
grep -i '^location:' headers.txt
jq -c '{InvoiceId, InvoiceNumber, Supplier, InvoiceAmount, ValidationStatus, ApprovalStatus, PaidStatus}' body.json
jq -c '[.invoiceLines[] | [.LineNumber, .LineType, .LineAmount]]' body.json

実行結果

HTTP 201
location: https://<このサイトのURL>/api/mock/fscmRestApi/resources/11.13.18.05/invoices/300245266
{"InvoiceId":300245266,"InvoiceNumber":"SMP-0007","Supplier":"サンプル商事株式会社","InvoiceAmount":330000,"ValidationStatus":"Not validated","ApprovalStatus":"Required","PaidStatus":"Unpaid"}
[[1,"Item",300000],[2,"Freight",30000]]

• 成功すると 201 と、新しい請求書の URL（Location ヘッダー）、作成後の内容が返ります。ValidationStatus や PaidStatus など、システムが決める項目には初期値が入っています
• InvoiceId は、モックが呼び出した時刻から採番します。値は毎回変わります
• このモックは保存しません。返ってきた InvoiceId で取得しようとしても、404 になります

curl -s -u learner:welcome1 -w '\nHTTP %{http_code}\n' "$BASE/invoices/$(jq -r .InvoiceId body.json)"

実行結果

invoices/300245266 was not found. Use the InvoiceId of an existing item (the "self" link of each item in GET invoices shows its URL).
HTTP 404

次に、重複エラーを起こします。同じ仕入先で、既存の請求書番号 SMP-0001 を使います。

jq '.InvoiceNumber = "SMP-0001"' new-invoice.json > dup-invoice.json

curl -s -u learner:welcome1 -X POST "$BASE/invoices" \
  -H 'Content-Type: application/json' -d @dup-invoice.json -w '\nHTTP %{http_code}\n'

実行結果

The invoice number SMP-0001 already exists for the supplier サンプル商事株式会社 (InvoiceId 300100001). Enter a unique invoice number for this supplier.
HTTP 400

重複は「同じ仕入先の中」で判定します。別の仕入先なら、同じ番号（例：1001）でも作れます。重複チェックは、モックでは既存の 30 件が相手です。さきほど作った SMP-0007 を、もう一度送っても重複にはなりません（保存していないためです）。

ステップ5 更新（PATCH）と削除（DELETE）

PATCH は、変更する項目だけを送ります。請求書 300100014 の説明と支払方法を変えます。

curl -s -u learner:welcome1 -X PATCH "$BASE/invoices/300100014" \
  -H 'Content-Type: application/json' \
  -d '{"Description": "3月分 配送運賃（確認済）", "PaymentMethod": "Check"}' \
  | jq -c '{InvoiceId, InvoiceNumber, Description, PaymentMethod, PaidStatus, LastUpdatedBy}'

curl -s -u learner:welcome1 -X PATCH "$BASE/invoices/300100014" \
  -H 'Content-Type: application/json' \
  -d '{"PaidStatus": "Paid"}' -w '\nHTTP %{http_code}\n'

curl -s -u learner:welcome1 -X PATCH "$BASE/invoices/300100014" \
  -H 'Content-Type: application/json' \
  -d '{"InvoiceAmount": 150000}' -w '\nHTTP %{http_code}\n'

実行結果

{"InvoiceId":300100014,"InvoiceNumber":"RU-2603","Description":"3月分 配送運賃（確認済）","PaymentMethod":"Check","PaidStatus":"Unpaid","LastUpdatedBy":"learner"}
The attribute PaidStatus is read-only and cannot be updated.
HTTP 400
The attribute InvoiceAmount cannot be updated after the invoice is created (mock API rule). Updatable attributes: AccountingDate, TermsDate, PaymentTerms, PaymentMethod, PayGroup, Description.
HTTP 400

1 つ目は成功（200）で、変更後の請求書が返ります。2 つ目は、システムが決める読取専用の項目（PaidStatus）です。3 つ目は、作成後に変えられない項目（InvoiceAmount）です。メッセージが、更新できる項目の一覧を教えてくれます。

DELETE は、このモックでは ValidationStatus が Not validated の請求書だけ削除できます。請求書 300100026（Not validated）と 300100001（Validated）で試します。

curl -s -u learner:welcome1 -X DELETE "$BASE/invoices/300100026" -w 'HTTP %{http_code}\n'
curl -s -u learner:welcome1 -X DELETE "$BASE/invoices/300100001" -w '\nHTTP %{http_code}\n'

実行結果

HTTP 204
The invoice SMP-0001 (InvoiceId 300100001) cannot be deleted because its validation status is Validated. Only invoices with the validation status Not validated can be deleted.
HTTP 400

削除の成功は 204（本文なし）です。ただし、このモックは削除もしないので、300100026 は、このあとも取得できます。

ステップ6 エラーの形を読む（Version 1 と Version 4）

同じ誤りを、Version 1（既定）と Version 4 で送って、応答を比べます。読取専用の PaidStatus と、存在しない項目 Foo を、1 つの PATCH に入れます。

curl -s -u learner:welcome1 -X PATCH "$BASE/invoices/300100014" \
  -H 'Content-Type: application/json' \
  -d '{"PaidStatus": "Paid", "Foo": 1}' -w '\nHTTP %{http_code}\n'

実行結果

The attribute PaidStatus is read-only and cannot be updated.
Foo is not an attribute of invoices.
HTTP 400

curl -s -u learner:welcome1 -X PATCH "$BASE/invoices/300100014" \
  -H 'Content-Type: application/json' -H 'REST-Framework-Version: 4' \
  -d '{"PaidStatus": "Paid", "Foo": 1}' | jq .

実行結果

{
  "title": "Bad Request",
  "status": "400",
  "o:errorDetails": [
    {
      "detail": "The attribute PaidStatus is read-only and cannot be updated.",
      "o:errorCode": "MOCK-READ-ONLY",
      "o:errorPath": "/PaidStatus"
    },
    {
      "detail": "Foo is not an attribute of invoices.",
      "o:errorCode": "MOCK-UNKNOWN-ATTRIBUTE",
      "o:errorPath": "/Foo"
    }
  ]
}

項目	Version 1〜3	Version 4 以降
形式	メッセージの文字列だけ	JSON（title・status・o:errorDetails）
複数のエラー	1 行ずつ	o:errorDetails の配列
原因の項目	メッセージの文中	o:errorPath（/PaidStatus のように指す）
プログラムでの判定	文字列を解析する	o:errorCode で分岐する

公式ドキュメントも、Version 4 以降は、アプリケーション固有のエラーコード、エラーの場所（パス）、原因のエラーの詳細を返すと説明しています。連携プログラムでは、Version 4 以降を指定して、o:errorCode と o:errorPath をログに残すと、原因調査が楽になります。

確認ポイント

• links の self と child の違いを説明できる
• 明細を、子の URL・expand・fields の 3 通りで取得できた
• Version 1 と 3 で、expand した子の形が違う（配列とコレクション）ことを確認した
• POST の必須項目エラーを読んで本文を直し、201 と Location を確認した
• 同じ仕入先の重複番号が 400 になり、別の仕入先なら通ることを理解した
• PATCH の成功、読取専用の項目、作成後に変えられない項目のエラーを区別できた
• DELETE が 204 になる請求書と 400 になる請求書を確認した
• Version 4 の o:errorPath から、原因の項目を指摘できた

課題と解答例

課題1 明細の合計と請求書の金額

請求書 300100019 について、明細（invoiceLines）の LineAmount の合計と、請求書の InvoiceAmount が一致するか確認してください。

解答例を表示

curl -s -u learner:welcome1 "$BASE/invoices/300100019/child/invoiceLines?onlyData=true" | jq '[.items[].LineAmount] | add'
curl -s -u learner:welcome1 "$BASE/invoices/300100019?onlyData=true&fields=InvoiceAmount" | jq '.InvoiceAmount'

実行結果

5845000
5845000

どちらも 5,845,000 で一致します（明細は 5,800,000 と運賃 45,000 の 2 行）。明細の件数が多い請求書では、子のコレクションにも limit と hasMore があります。合計を取る前に、hasMore が false であることを確認してください。

課題2 運賃（Freight）明細がある請求書

運賃（LineType が Freight）の明細がある請求書は、全部で何件ですか。また、InvoiceId の小さい順に 3 件について、請求書番号と運賃の金額を、1 回のリクエストで表示してください。

解答例を表示

子リソースの属性で絞り込む q は、Version 2 以降の機能です。子を items の形で受け取るため、Version 3 を指定します。

curl -s -G -u learner:welcome1 -H 'REST-Framework-Version: 3' "$BASE/invoices?limit=3&orderBy=InvoiceId&totalResults=true&onlyData=true&fields=InvoiceNumber;invoiceLines:LineType,LineAmount" \
  --data-urlencode "q=invoiceLines.LineType = 'Freight'" \
  | jq -c '{totalResults}, (.items[] | {InvoiceNumber, freight: ([.invoiceLines.items[] | select(.LineType == "Freight") | .LineAmount] | add)})'

実行結果

{"totalResults":12}
{"InvoiceNumber":"SMP-0001","freight":5000}
{"InvoiceNumber":"RU-2601","freight":132000}
{"InvoiceNumber":"SL-88231","freight":12500}

12 件です。q の条件は「運賃の明細を持つ請求書」を選ぶだけで、子の中身は絞りません。運賃の行だけを集計するには、jq で Freight の行を選びます。

課題3 クレジットメモの作成

サンプル商事株式会社（サイト TOKYO、営業単位 JP01 Business Unit）の返品に伴うクレジットメモ CM-0001（金額 -50,000 円、請求書日付 2026-10-05）を作成してください。次に、金額を +50,000 にして送り、エラーを確認してください。

解答例を表示

InvoiceType に Credit memo を指定し、金額を負の値にします。

cat > credit.json <<'EOF'
{
  "InvoiceNumber": "CM-0001",
  "InvoiceType": "Credit memo",
  "InvoiceCurrency": "JPY",
  "InvoiceAmount": -50000,
  "InvoiceDate": "2026-10-05",
  "BusinessUnit": "JP01 Business Unit",
  "Supplier": "サンプル商事株式会社",
  "SupplierSite": "TOKYO",
  "Description": "返品に伴うクレジットメモ"
}
EOF

curl -s -u learner:welcome1 -X POST "$BASE/invoices" \
  -H 'Content-Type: application/json' -d @credit.json \
  | jq -c '{InvoiceNumber, InvoiceType, InvoiceAmount, ValidationStatus}'

jq '.InvoiceAmount = 50000' credit.json > credit-positive.json
curl -s -u learner:welcome1 -X POST "$BASE/invoices" \
  -H 'Content-Type: application/json' -d @credit-positive.json -w '\nHTTP %{http_code}\n'

実行結果

{"InvoiceNumber":"CM-0001","InvoiceType":"Credit memo","InvoiceAmount":-50000,"ValidationStatus":"Not validated"}
The invoice amount of a Credit memo must be negative.
HTTP 400

金額の符号は、請求書タイプとの組合せで検証されます。InvoiceType を省くと Standard になり、負の金額は拒否されます。

課題4 取消済みの請求書を更新する

請求書 300100012 の Description を 再確認 に変えてください。失敗したら、その請求書の状態を調べて、原因を説明してください。

解答例を表示

curl -s -u learner:welcome1 -X PATCH "$BASE/invoices/300100012" \
  -H 'Content-Type: application/json' -d '{"Description": "再確認"}' -w '\nHTTP %{http_code}\n'

curl -s -u learner:welcome1 "$BASE/invoices/300100012?onlyData=true&fields=InvoiceNumber,CanceledFlag,ValidationStatus,PaidStatus" | jq -c '.'

実行結果

The invoice 1002 (InvoiceId 300100012) is canceled and cannot be updated.
HTTP 400
{"InvoiceNumber":"1002","ValidationStatus":"Validated","PaidStatus":"Unpaid","CanceledFlag":true}

この請求書は取消済み（CanceledFlag が true）なので、更新できません。項目の誤りではなく、請求書の状態に起因するエラーです。メッセージだけで原因が分かりますが、状態は GET で確認します。

よくあるエラーと対処

メッセージは、このモックのものです（実機とは異なります）。

症状	原因と対処
415（The Content-Type … is not supported）	-d だけの curl は form 形式で送る。-H 'Content-Type: application/json' を付ける
400（The request body is not valid JSON）	JSON の構文の誤り（カンマ・引用符）。jq . new-invoice.json で確認する
400（The attribute … is required.）	必須項目の不足。不足分がまとめて返るので、すべて足して送り直す
400（The supplier site … does not exist … Valid sites: …）	仕入先とサイトの組合せが違う。メッセージの候補から選ぶ
400（The value … is not valid for … Valid values: …）	選択肢にない値（例：PaymentMethod に Cash）。候補から選ぶ
400（The invoice number … already exists for the supplier …）	同じ仕入先で請求書番号が重複している。別の番号にする
400（… is read-only や cannot be updated after the invoice is created）	読取専用の項目、または作成後に変えられない項目を PATCH に含めた。更新できる項目だけを送る
400（… is canceled and cannot be updated）	取消済みの請求書は更新できない
400（… cannot be deleted because its validation status is …）	このモックは、Not validated の請求書だけ削除できる
404（… was not found）	URL のキーが違う。links の href を使う
405（The method … is not allowed）	そのリソースで使えないメソッド。Allow ヘッダーに使えるメソッドが入る
作成した請求書が取得できない（404）	このモックは保存しない。実機では保存される

発展課題

1. 一括削除のループ：q=ValidationStatus=Not validated で削除できる請求書を探し、すべてに DELETE を送るループを書いてください（for ID in $(curl … | jq -r '.items[].InvoiceId') の形）。実機で同じことをする前に、何を確認すべきか（対象の一覧、テスト環境、取り消せるか）を書き出してください
2. 別の仕入先で同じ請求書番号：1001 は 2 つの仕入先に存在します。サンプル商事株式会社で 1001 を作成し、成功することを確認してください
3. 明細のエラーの場所：作成時の invoiceLines に、不正な LineType（例：Misc）を入れます。Version 4 で送り、o:errorPath が明細の位置（/invoiceLines/0/LineType のような形）を指すか確認してください
4. 再試行と重複：POST にヘッダー X-Mock-Fault: 500 を付けて失敗させます。実機で、POST が失敗（タイムアウトを含む）したときに再送すると、請求書が重複して作られる恐れがあります。重複を防ぐ設計（請求書番号の重複チェック、再送前の検索）を考えてください。再試行の実装は REST 演習3 で扱います

実機との違い

項目	このモック	実機の Fusion
保存	作成・更新・削除は、検証して結果を返すだけで保存しない	保存される。誤って実行すると、データが変わる
請求書の URL のキー	invoices/300100001（InvoiceId）	invoices/{invoicesUniqID}。公式は「複合キーのハッシュ値で、クライアントは作らず、コレクションを検索して得る」と説明
明細の URL のキー	invoiceLines/1（LineNumber）	同様にハッシュ値（{invoiceLinesUniqID}）。links の href をたどる
子リソースの操作	明細は GET のみ。作成時に親と一緒に渡せる	明細にも、作成・取得・更新・削除がある（公式の Invoice Lines）
作成の必須項目	InvoiceNumber・BusinessUnit・Supplier・SupplierSite・InvoiceCurrency・InvoiceAmount・InvoiceDate	公式のスキーマで必須と示される項目は、AccountingDate・BusinessUnit・InvoiceAmount・InvoiceCurrency・InvoiceDate・InvoiceNumber・PaymentCurrency・PaymentMethodCode・TermsDate。Supplier・SupplierSite はスキーマの必須には含まれないが、属性の説明に「作成時に値を指定する」とある
更新できる項目	AccountingDate・TermsDate・PaymentTerms・PaymentMethod・PayGroup・Description	公式は、BusinessUnit・Supplier・SupplierSite は作成後に変更できない、PayGroup は更新できる、と説明。ほかの項目は公式で確認する
削除できる条件	ValidationStatus が Not validated の請求書だけ（モックの規則）	公式の Delete an invoice には条件の記載がない。成功は 204
アクション	なし	validateInvoice・cancelInvoice など、/invoices/action/… のアクションがある
Content-Type	application/json と application/vnd.oracle.adf.resourceitem+json を受け付ける	公式の作成・更新では application/json だけが示されている
エラー	MOCK-… のコード。Version 4 は Accept なしでも JSON	Oracle のコード（公式の例：AP:::AP_RS_INV_NUM_DUPLICATE_VALUE）。公式の Version 4 の例は、Accept: application/vnd.oracle.adf.resourceitem+json,application/vnd.oracle.adf.error+json を付けている

• 実機では、請求書日付を PATCH で変えても、関連項目（支払期日など）は自動では更新されません（公式ドキュメントの注意）。関連項目も自分で更新します
• このモックの値（JP01 Business Unit、TOKYO、Net 30 など）は、練習用の架空の値です。実機では、自社の営業単位・仕入先・サイト・支払条件の名前を使います
• 練習用 API で通った本文が、実機でそのまま通るとは限りません。必須項目と値は、公式ドキュメントとテスト環境で確認してください

公式ドキュメント

• Create an invoice（作成の本文の項目）
• Update an invoice（更新できる項目）
• Delete an invoice
• Get an invoice（expand・fields・onlyData、URL のキー）
• Invoice Lines（子リソースの操作一覧）
• Set the REST Framework Version（Version 3 の子の形、Version 4 のエラー）

関連ページ

• REST 演習1：請求書を検索・絞り込みする
• REST 演習3：Python でページングしながら全件取得する
• 練習用 API プレイグラウンド
• REST API の基本（URL・クエリパラメータ・ページング）
• REST API 応用（子リソース・作成更新・フレームワークバージョン・エラー）
• REST API・ESS チートシート
• ハンズオン演習の進め方と環境準備