APIレスポンスを比較して互換性を評価する方法。
構造の変更と値の変更を分けます。例の値が変わっても必ず API 契約が壊れるとは限りませんが、フィールド削除は重要な場合があります。
作業手順をタスクに合わせましょう。
応答の構造と値を別々に比較し、各変更へのパスを保ちます。削除・改名されたフィールドと例の値の変更を区別し、利用側の実際の要件で互換性を評価してください。
- 用意するもの
- 二つの応答例と比較ルール。
- 得られるもの
- スキーマと値の変更および互換性への懸念。
入力と結果を確認しましょう。
説明用の入力と出力 · 実際の WebAct 実行ではない学習用サンプル
入力項目サンプル個
Compare response field sets. Old: {"id":"A1","name":"Ada"}. New: {"id":"A1","display_name":"Ada"}. No API compatibility contract supplied.完成例
Unchanged field: id. Removed field: name. Added field: display_name. Potential impact: clients reading name may fail or lose displayed text. A rename is plausible, but the samples alone do not prove semantic equivalence or the full compatibility policy.
この入力をプロンプトに読み込み、WebAct にコピーして試してください。結果は掲載例と異なる場合があります。
判断のポイントとトラブル対処。
例の値が変わると自動的に API 契約が壊れますか？
いいえ。値は正当に変わることがあります。スキーマ、意味、利用側の前提によって変更の重要性が決まります。
改名したフィールドが無関係な削除と追加に見えるのはなぜですか？
構造の差分は意図を証明できません。改名の可能性を記し、変更文書と利用側の使い方で確認してください。
自分の資料で試しましょう。
タスクのプロンプト内の例を自分の資料に置き換えてください。必要な要件を残し、タスクを WebAct にコピーします。
タスクを調整してコピー ↑