REST 演習1：請求書を検索・絞り込みする

この演習の結論

• 一覧の取得は「limit で件数を決める → hasMore で続きの有無を見る → 一意の属性で orderBy して並びを固定する」が基本です。limit を付けない取得は、既定の件数で止まっていても気づきにくく、事故のもとです。
• 応答を小さくする順番は「fields で項目を絞る → onlyData=true で links を省く → q で行を絞る」です。この演習のデータでは、約 45 KB の応答が約 3 KB になります。
• q の書き方は REST-Framework-Version で変わります。Version 1（ヘッダーなしの既定）は 項目=値 を ; でつなぎ、Version 2 以降は and・or・括弧・IN・BETWEEN・LIKE・UPPER() が使えます。取り違えると 400 になります。

この演習で身につくこと

• limit・offset・hasMore・totalResults を読み、全件を取り切るまでページを進められる
• orderBy で並びを指定し（降順・複数キー）、ページングを安定させられる
• fields と onlyData で応答を小さくできる
• q で行を絞り込める。Version 1 と Version 2 の構文の違いを説明し、取り違えたときのエラーを読んで直せる

URL の組み立てとパラメータの一覧は REST API の基本、子リソース・Version・エラーの詳細は REST API 応用 を参照してください。

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

シナリオ（架空）

サンプル商事株式会社の経理部で、AP 担当者が請求書の状況を REST API で確認します。「未払いの請求書を金額順に見る」「四半期の請求書を抜き出す」「全件を取り切る」の 3 つを、自動化する前の準備として試します。

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

練習用モック API を使います。Fusion 環境もユーザー登録も要りません。データは架空の請求書 30 件（InvoiceId が 300100001〜300100030）です。

• bash と curl が使えるターミナル（macOS、Linux、Windows の WSL や Git Bash）を使います。出力の整形に jq があると便利です（なければ | jq … の部分を外し、結果をそのまま読みます）
• ターミナルを使えない場合は、ブラウザの 練習用 API プレイグラウンド で同じリクエストを送れます。パスと各パラメータ（limit・orderBy・q など）、REST-Framework-Version を欄に入れて送信します。入力例の「describe（属性の一覧）」「ページング」「絞り込み：Version 1 の q」「絞り込み：Version 2 以降の q」「Version と q の構文が合わない（400）」から始めると便利です。同じ内容の curl も表示されます

準備（最初に 1 回）

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

<このサイトのURL> は、このサイトのアドレス（例：https://example.pages.dev）に置き換えます。この演習で使う curl のオプションは次のとおりです。

オプション	意味
-s	進捗表示を出さない
-u learner:welcome1	Basic 認証（モックはどんな値でも通します）
-G --data-urlencode "q=…"	値を URL エンコードしてクエリ文字列に付ける（GET のまま）
-H 'REST-Framework-Version: 2'	Version を指定する（付けなければ 1）
-w '\nHTTP %{http_code}\n'	応答のあとに HTTP ステータスを表示する

Fusion 環境ありルート

同じ手順を、実機の請求書（invoices）で試せます。次の 3 点を読み替えます。

• BASE を https://<your-pod>.fa.<region>.oraclecloud.com/fscmRestApi/resources/11.13.18.05 にします
• -u learner:welcome1 を -u "$FUSION_USER:$FUSION_PASSWORD" にします（環境変数から読み、パスワードをコマンドに直書きしません）
• q の値（仕入先名・金額・日付）を、テスト環境のデータに合わせて変えます

REST で請求書を参照できるユーザー（統合ユーザー）が必要です。必要なロールは、公式の invoices のページには書かれていません。セキュリティ担当に確認してください（認証・認可）。属性名は、ステップ1 の describe で確認します。本番環境ではなく、テスト環境を使います。

手順

ステップ1 使える属性を調べる（describe）

q・orderBy・fields には、リソースの属性名を使います。属性は describe で調べます。

curl -s -u learner:welcome1 "$BASE/invoices/describe" \
  | jq -c '.Resources.invoices.attributes[] | {name, type, queryable}' | head -n 5

実行結果

{"name":"InvoiceId","type":"integer","queryable":true}
{"name":"InvoiceNumber","type":"string","queryable":true}
{"name":"InvoiceType","type":"string","queryable":true}
{"name":"InvoiceSource","type":"string","queryable":true}
{"name":"BusinessUnit","type":"string","queryable":true}

queryable が true の属性だけを q に使えます。false の属性を使うと 400 になります（公式ドキュメントの説明）。このモックの invoices は 29 属性で、すべて true です。

ステップ2 最初の一覧を取る（limit・hasMore）

curl -s -u learner:welcome1 "$BASE/invoices?limit=2&onlyData=true&fields=InvoiceId,InvoiceNumber"

実行結果

{
  "items": [
    {
      "InvoiceId": 300100001,
      "InvoiceNumber": "SMP-0001"
    },
    {
      "InvoiceId": 300100002,
      "InvoiceNumber": "1001"
    }
  ],
  "count": 2,
  "hasMore": true,
  "limit": 2,
  "offset": 0,
  "links": [
    {
      "rel": "self",
      "href": "https://<このサイトのURL>/api/mock/fscmRestApi/resources/11.13.18.05/invoices",
      "name": "invoices",
      "kind": "collection"
    }
  ]
}

項目	意味
items	取得した行（配列）
count	今回返した件数
hasMore	まだ続きがあるか。true なら次のページがある
limit・offset	件数の上限と開始位置（offset は 0 始まり）
links	コレクション自身の URL など

limit を付けないと、このモックは 25 件で止まります。請求書は 30 件あるので、hasMore が true になります。

curl -s -u learner:welcome1 "$BASE/invoices?onlyData=true&fields=InvoiceId" | jq '{count, hasMore, limit, offset}'

実行結果

{
  "count": 25,
  "hasMore": true,
  "limit": 25,
  "offset": 0
}

ステップ3 ページを進める（offset・totalResults・orderBy）

offset を limit ずつ増やして、最後のページ（hasMore が false）まで進めます。並びを固定するため orderBy=InvoiceId を付け、総件数を知るため totalResults=true を付けます。

for OFFSET in 0 10 20 30; do
  curl -s -u learner:welcome1 "$BASE/invoices?limit=10&offset=$OFFSET&orderBy=InvoiceId&totalResults=true&onlyData=true&fields=InvoiceId" \
    | jq -c '{offset, count, hasMore, totalResults, first: .items[0].InvoiceId}'
done

実行結果

{"offset":0,"count":10,"hasMore":true,"totalResults":30,"first":300100001}
{"offset":10,"count":10,"hasMore":true,"totalResults":30,"first":300100011}
{"offset":20,"count":10,"hasMore":false,"totalResults":30,"first":300100021}
{"offset":30,"count":0,"hasMore":false,"totalResults":30,"first":null}

• hasMore が false になった offset=20 が最後のページです。offset=30 は最後の行の次の位置なので、0 件です（公式ドキュメントも、offset が件数を超えると 0 件と説明しています）
• totalResults は、totalResults=true を付けたときだけ返ります
• 公式ドキュメントは、limit と offset を指定しただけでは結果が整列されないと注意しています。主キーのような一意の属性で orderBy すると、ページの間で重複や抜けが起きにくくなります

ステップ4 並べ替える（orderBy）

curl -s -u learner:welcome1 "$BASE/invoices?limit=3&orderBy=InvoiceAmount:desc&onlyData=true&fields=InvoiceId,InvoiceNumber,Supplier,InvoiceAmount" \
  | jq -c '.items[]'

実行結果

{"InvoiceId":300100019,"InvoiceNumber":"KK-2602","Supplier":"架空工業株式会社","InvoiceAmount":5845000}
{"InvoiceId":300100006,"InvoiceNumber":"KK-2601","Supplier":"架空工業株式会社","InvoiceAmount":4650000}
{"InvoiceId":300100017,"InvoiceNumber":"SMP-0004","Supplier":"サンプル商事株式会社","InvoiceAmount":2412000}

• :desc が降順、:asc または省略が昇順です
• 複数のキーはカンマでつなぎます。左のキーが優先です
• 文字列の並びは、大文字と小文字を区別します（公式ドキュメントの説明）

curl -s -u learner:welcome1 "$BASE/invoices?limit=4&orderBy=Supplier,InvoiceAmount:desc&onlyData=true&fields=InvoiceId,Supplier,InvoiceAmount" \
  | jq -c '.items[]'

実行結果

{"InvoiceId":300100010,"Supplier":"Example Software LLC","InvoiceAmount":24000}
{"InvoiceId":300100028,"Supplier":"Example Software LLC","InvoiceAmount":4800}
{"InvoiceId":300100020,"Supplier":"Sample Logistics Inc.","InvoiceAmount":18420.75}
{"InvoiceId":300100008,"Supplier":"Sample Logistics Inc.","InvoiceAmount":12850.5}

仕入先名の昇順に並び、同じ仕入先の中は金額の降順になっています。

ステップ5 取得量を減らす（fields・onlyData）

3 つのリクエストの応答サイズ（バイト数）を比べます。

curl -s -u learner:welcome1 "$BASE/invoices" | wc -c
curl -s -u learner:welcome1 "$BASE/invoices?onlyData=true" | wc -c
curl -s -u learner:welcome1 "$BASE/invoices?onlyData=true&fields=InvoiceId,InvoiceNumber,InvoiceAmount" | wc -c

リクエスト	応答サイズの目安（25 件）
そのまま	約 45 KB
onlyData=true	約 27 KB
onlyData=true と fields（3 項目）	約 3 KB

サイズは、サイトのホスト名の長さで少し変わります。fields は返す属性を絞り、onlyData=true は各行の links（自分自身や子リソースへの URL）を省きます。公式ドキュメントは、onlyData を「項目のペイロードをデータだけにする（links セクションなどを含めない）」と説明し、調達の Playbook は「応答からリンクをすべて除いて、サイズを減らす」と説明しています。このモックは、各行の links を省き、コレクション全体の links（self）は残します。実機でコレクション全体の links が残るかどうかは、環境で確認してください。

ステップ6 行を絞り込む（q・Version 1）

ヘッダーを付けなければ Version 1 です。q は「項目 演算子 値」で書き、項目の違う条件は ; でつなぎます（AND）。同じ項目の範囲は、2 つ目の項目名を省いて and でつなげます。演算子は =・!=・>・>=・<・<= を使います。q には空白・日本語・> などが入るので、-G --data-urlencode で渡します。

curl -s -G -u learner:welcome1 "$BASE/invoices?orderBy=InvoiceId&totalResults=true&onlyData=true&fields=InvoiceId,InvoiceNumber,InvoiceAmount,PaidStatus" \
  --data-urlencode "q=InvoiceAmount>=100000 and <=500000;PaidStatus!=Paid" \
  | jq -c '{totalResults, count, hasMore}, (.items[] | [.InvoiceId, .InvoiceNumber, .InvoiceAmount, .PaidStatus])'

実行結果

{"totalResults":3,"count":3,"hasMore":false}
[300100014,"RU-2603",143400,"Unpaid"]
[300100026,"DM-1003",156000,"Unpaid"]
[300100030,"RU-2604",138000,"Unpaid"]

「金額が 10 万円以上 50 万円以下で、支払済みではない」請求書が 3 件です。この形は、公式ドキュメントの Version 1 の例（q=deptno>=10 and <=30;loc!=NY）と同じです。文字列に引用符を付けない書き方も、この例に合わせています（このモックは引用符付きも受け付けます）。

ステップ7 行を絞り込む（q・Version 2 以降）

REST-Framework-Version: 2 を付けると、q は and・or・括弧が使える式の書き方になります。文字列と日付は単一引用符 '…' で囲みます（公式の例も DeptName = 'SALES'、HireDate = '1999-01-01' の形です）。

curl -s -G -u learner:welcome1 -H 'REST-Framework-Version: 2' "$BASE/invoices?orderBy=InvoiceAmount:desc&totalResults=true&onlyData=true&fields=InvoiceId,InvoiceNumber,InvoiceAmount,PaidStatus" \
  --data-urlencode "q=InvoiceAmount >= 1000000 and (PaidStatus = 'Unpaid' or PaidStatus = 'Partially paid')" \
  | jq -c '{totalResults, count, hasMore}, (.items[] | [.InvoiceId, .InvoiceNumber, .InvoiceAmount, .PaidStatus])'

実行結果

{"totalResults":2,"count":2,"hasMore":false}
[300100019,"KK-2602",5845000,"Partially paid"]
[300100017,"SMP-0004",2412000,"Unpaid"]

Version 2 以降で使える主な書き方は次のとおりです。

目的	書き方の例
複数の候補	PaidStatus IN ('Unpaid', 'Partially paid')
範囲	InvoiceAmount BETWEEN 100000 AND 500000
あいまい検索	InvoiceNumber LIKE 'SMP-%'
大文字小文字を無視	UPPER(Supplier) LIKE '%LOGI%'
空かどうか	PurchaseOrderNumber IS NULL
子リソースの属性	invoiceLines.LineType = 'Freight'

LIKE は大文字小文字を区別します

このモックの LIKE は、大文字小文字を区別します。Supplier LIKE '%logi%' は 0 件ですが、UPPER(Supplier) LIKE '%LOGI%' は 3 件になります。なお、公式の例は UPPER(DeptName) LIKE UPPER('%e%') のように右辺も UPPER() で包みますが、このモックは右辺の UPPER() に対応していません。右辺は最初から大文字で書いてください。

ステップ8 Version を取り違えたときのエラーを見る

Version 1（ヘッダーなし）で、別の項目を and でつないでみます。

curl -s -G -u learner:welcome1 -w '\nHTTP %{http_code}\n' "$BASE/invoices?limit=1" \
  --data-urlencode "q=InvoiceAmount>100000 and PaidStatus=Unpaid"

実行結果

Combining different attributes with and / or cannot be used in q with REST-Framework-Version 1. Specify the header REST-Framework-Version: 2 (or later), or use the Version 1 syntax: <attribute><operator><value> combined with ';' (for example: InvoiceAmount>100000;PaidStatus=Unpaid).
HTTP 400

次に、Version 2 で ; を使ってみます。

curl -s -G -u learner:welcome1 -H 'REST-Framework-Version: 2' -w '\nHTTP %{http_code}\n' "$BASE/invoices?limit=1" \
  --data-urlencode "q=InvoiceAmount>100000;PaidStatus=Unpaid"

実行結果

';' cannot be used to combine conditions with REST-Framework-Version 2 or later. Use and / or instead (for example: InvoiceAmount > 100000 and PaidStatus = 'Unpaid').
HTTP 400

どちらも 400 です。メッセージが直し方を示しています（Version 1 から 3 のエラーは、このようにテキストで返ります。形式の違いは REST 演習2 で扱います）。Version ごとの書き方の違いをまとめます。

やりたいこと	Version 1	Version 2 以降
項目の違う条件を AND でつなぐ	A=x;B>1	A = 'x' and B > 1
OR・括弧	; は AND のみ	or・( ) が使える
範囲	A>=1 and <=9	A BETWEEN 1 AND 9
複数の候補	使えない（IN は Version 2 以降）	A IN ('x', 'y')
子の属性・UPPER()	使えない	使える
文字列・日付	公式の例は引用符なし	単一引用符で囲む

確認ポイント

• limit を付けないと 25 件で止まり、hasMore が true になることを確認した
• offset を 0・10・20 と進めて 30 件を取り、offset=20 の hasMore が false だった
• orderBy=InvoiceAmount:desc と、複数キーの orderBy で並びが変わることを確認した
• onlyData と fields で、応答サイズが約 45 KB から約 3 KB に減ることを確認した
• Version 1 の q で、; による AND と and <= の範囲指定ができた
• Version 2 の q で、and・or・括弧が使えた
• Version を取り違えたときの 400 のメッセージを読んで、q を直せた

課題と解答例

課題は curl かプレイグラウンドで解きます。解答例は、解いてから開いて確認してください。

課題1 未払い請求書の上位 5 件（Version 1）

支払状況（PaidStatus）が Unpaid の請求書を、金額（InvoiceAmount）の大きい順に上位 5 件取得してください。未払いが全部で何件あるかも表示します。

解答例を表示

curl -s -G -u learner:welcome1 "$BASE/invoices?orderBy=InvoiceAmount:desc&limit=5&totalResults=true&onlyData=true&fields=InvoiceId,InvoiceNumber,Supplier,InvoiceAmount" \
  --data-urlencode "q=PaidStatus=Unpaid" \
  | jq -c '{totalResults, count, hasMore}, (.items[] | [.InvoiceId, .InvoiceNumber, .Supplier, .InvoiceAmount])'

実行結果

{"totalResults":14,"count":5,"hasMore":true}
[300100017,"SMP-0004","サンプル商事株式会社",2412000]
[300100024,"MS-26-011","見本システム株式会社",990000]
[300100016,"DM-1002","デモ電機株式会社",867300]
[300100029,"SMP-0006","サンプル商事株式会社",721000]
[300100026,"DM-1003","デモ電機株式会社",156000]

未払いは全部で 14 件（totalResults）で、ここには上位 5 件だけが出ています（hasMore が true）。orderBy を付けないと、「上位」の意味がなくなります。

課題2 サンプル商事株式会社の 10 万円超の請求書（Version 1）

仕入先が サンプル商事株式会社 で、金額が 100,000 を超える請求書を、InvoiceId の順に取得してください。InvoiceId・請求書番号・金額・支払状況を表示します。

解答例を表示

curl -s -G -u learner:welcome1 "$BASE/invoices?orderBy=InvoiceId&onlyData=true&fields=InvoiceId,InvoiceNumber,InvoiceAmount,PaidStatus" \
  --data-urlencode "q=Supplier=サンプル商事株式会社;InvoiceAmount>100000" \
  | jq -c '.items[] | [.InvoiceId, .InvoiceNumber, .InvoiceAmount, .PaidStatus]'

実行結果

[300100001,"SMP-0001",485000,"Paid"]
[300100007,"SMP-0002",1250000,"Paid"]
[300100011,"SMP-0003",508000,"Partially paid"]
[300100017,"SMP-0004",2412000,"Unpaid"]
[300100029,"SMP-0006",721000,"Unpaid"]

SMP-0005（InvoiceId 300100018）は、金額が -120,000 のクレジットメモなので外れます。日本語を含むので、-G --data-urlencode を使います。

課題3 2026 年 4〜6 月の請求書の件数（Version 1 と 2）

請求書日付（InvoiceDate）が 2026-04-01 から 2026-06-30 までの請求書は何件ですか。Version 1 と Version 2 の両方で、totalResults を見て答えてください。

解答例を表示

# Version 1
curl -s -G -u learner:welcome1 "$BASE/invoices?limit=1&totalResults=true&onlyData=true&fields=InvoiceId" \
  --data-urlencode "q=InvoiceDate>=2026-04-01;InvoiceDate<=2026-06-30" | jq -c '{totalResults}'

# Version 2
curl -s -G -u learner:welcome1 -H 'REST-Framework-Version: 2' "$BASE/invoices?limit=1&totalResults=true&onlyData=true&fields=InvoiceId" \
  --data-urlencode "q=InvoiceDate BETWEEN '2026-04-01' AND '2026-06-30'" | jq -c '{totalResults}'

実行結果

{"totalResults":8}
{"totalResults":8}

どちらも 8 件です。件数だけが欲しいときは、limit=1 と fields で応答を小さくして、totalResults だけを見ます。Version 1 では InvoiceDate>=2026-04-01 and <=2026-06-30 とも書けます。

課題4 limit=7 で全件を取るには何回必要か

limit=7 で 30 件すべてを取ります。何回のリクエストが必要で、各回の count と hasMore はどうなりますか。orderBy=InvoiceId を付けて、offset を 7 ずつ増やして確かめてください。

解答例を表示

for OFFSET in 0 7 14 21 28 35; do
  curl -s -u learner:welcome1 "$BASE/invoices?limit=7&offset=$OFFSET&orderBy=InvoiceId&onlyData=true&fields=InvoiceId" \
    | jq -c '{offset, count, hasMore}'
done

実行結果

{"offset":0,"count":7,"hasMore":true}
{"offset":7,"count":7,"hasMore":true}
{"offset":14,"count":7,"hasMore":true}
{"offset":21,"count":7,"hasMore":true}
{"offset":28,"count":2,"hasMore":false}
{"offset":35,"count":0,"hasMore":false}

5 回です。最後のページ（offset=28）は count が 2 で、hasMore が false になります。offset=35 は不要な 6 回目です。「count が limit より少ないこと」ではなく、「hasMore が false であること」を終了の条件にします。

課題5 Version 2 でしか書けない条件を体験する

1. 仕入先が サンプル商事株式会社 または テスト物産株式会社 の請求書の件数を、Version 2 の IN で求めてください
2. 同じ q を、Version 1（ヘッダーなし）で送ると何が起きますか
3. Version 1 のまま、同じ件数を求めるには、どうしますか

解答例を表示

# 1. Version 2
curl -s -G -u learner:welcome1 -H 'REST-Framework-Version: 2' "$BASE/invoices?limit=1&totalResults=true&onlyData=true&fields=InvoiceId" \
  --data-urlencode "q=Supplier IN ('サンプル商事株式会社', 'テスト物産株式会社')" | jq -c '{totalResults}'

# 2. Version 1（ヘッダーなし）
curl -s -G -u learner:welcome1 -w '\nHTTP %{http_code}\n' "$BASE/invoices?limit=1" \
  --data-urlencode "q=Supplier IN ('サンプル商事株式会社', 'テスト物産株式会社')"

# 3. Version 1 で仕入先ごとに分ける
for S in サンプル商事株式会社 テスト物産株式会社; do
  curl -s -G -u learner:welcome1 "$BASE/invoices?limit=1&totalResults=true&onlyData=true&fields=InvoiceId" \
    --data-urlencode "q=Supplier=$S" | jq -c '{totalResults}'
done

実行結果

{"totalResults":9}
The IN operator cannot be used in q with REST-Framework-Version 1. Specify the header REST-Framework-Version: 2 (or later), or use the Version 1 syntax: <attribute><operator><value> combined with ';' (for example: InvoiceAmount>100000;PaidStatus=Unpaid).
HTTP 400
{"totalResults":6}
{"totalResults":3}

1. Version 2 なら、1 回のリクエストで 9 件です
2. Version 1 では IN が使えず、400 になります
3. 仕入先ごとにリクエストを分け、クライアント側で合算します（6 件 + 3 件 = 9 件）。件数が多い場合は、リクエストごとにページングも必要です

よくあるエラーと対処

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

症状	原因と対処
401 Unauthorized	認証情報がない。-u learner:welcome1 を付ける
400（Combining different attributes with and / or …）	Version 1 で、別の項目を and・or でつないだ。; でつなぐか、REST-Framework-Version: 2 を付けて and・or で書く
400（';' cannot be used …）	Version 2 以降で ; を使った。and に直す
400（… Enclose string values in single quotes）	Version 2 以降で、文字列や日付を引用符なしで書いた。'Unpaid' のように単一引用符で囲む
400（… is not an attribute of invoices.）	q・orderBy・fields の属性名の綴りや大文字小文字の誤り。describe で確認する
400（The value … of the limit parameter is not valid）	limit は 1 以上、offset は 0 以上の整数にする
0 件になる	値の大文字小文字が違う。LIKE は大文字小文字を区別する。条件が厳しすぎる、offset が総件数を超えている場合もある
日本語や % を含む q がおかしくなる	URL エンコードされていない。-G --data-urlencode "q=…" を使う
30 件あるのに 25 件しか取れない	既定の limit（このモックは 25）で止まっている。hasMore が true なら続きを取る

発展課題

1. キーセット方式のページング：orderBy=InvoiceId&limit=5 に q=InvoiceId>300100010 を付けると、offset を使わずに「ID が 300100010 より後ろ」の 5 件を取れます。前のページの最後の InvoiceId を次の q に使うループを考えてください。公式ドキュメントにも、同じ考え方の例（orderBy=OptyId&q=OptyId>1000）があります。Python での実装は REST 演習3 で扱います
2. limit の境界：limit=501・limit=0・offset=-1 を送り、応答の limit と HTTP ステータスを記録してください
3. 別のリソース：suppliers（仕入先）で describe を見て、Version 2 の q で BusinessRelationship = 'SPEND_AUTHORIZED' の仕入先を絞り込んでください
4. 実機との比較（Fusion 環境がある人）：同じ手順を実機の invoices で試し、結果の違いを次の「実機との違い」の表に書き足してください

実機との違い

項目	このモック	実機の Fusion
データ	架空の請求書 30 件。内容は固定	自社のデータ。件数と値は環境による
属性	invoices の 29 属性だけ（実機にもある属性）	属性はもっと多い。describe で確認する
既定の limit と上限	既定 25、上限 500（501 以上は 500 に丸める）	公式の Manage Collections と Get all invoices には、既定値も上限も書かれていない。調達の Integration Playbook には、調達の REST API は 1 回に 500 件を超えて返さないとある。応答の limit で確認する
totalResults	正確な総件数	公式は推定の行数（estimated row count）と説明している
onlyData=true	各行の links を省く。コレクション全体の links（self）は残る	公式は、項目のペイロードをデータだけにすると説明し、調達の Playbook は応答からすべてのリンクを除くと説明している。コレクション全体の links が残るかは、実機で確認する
q の演算子	NOT IN・NOT LIKE・NOT BETWEEN・右辺の UPPER() は使えない	公式は、これらを使える演算子・書き方として載せている
Version 1 の q	LIKE で % が使える	公式は % を Version 2 以降のみと説明している
エラー	英語の簡易メッセージ（モック独自）	Oracle のメッセージとコード
応答の見た目	整形されている	整形されていないことがある。jq で整形する

• Version 1 の q の引用符の扱いは、公式の例（loc!=NY）に合わせています。文字列に空白や記号が入る場合の書き方は、環境で確認してください
• 練習用 API で動いた q が実機でそのまま動くとは限りません。属性名は describe と公式ドキュメントで確認してください
• 作成・更新・削除は、この演習では扱いません。REST 演習2 で扱います

公式ドキュメント

• Manage Collections（q・orderBy・ページング、Version 1 と 2 の q の違い）
• Set the REST Framework Version（Version ごとの変更点）
• Get all invoices（invoices の問い合わせパラメータと finder）
• REST APIs（Integration Playbooks for Procurement 26D）（1 回に返す件数の上限、fields・onlyData の推奨）

関連ページ

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