リソース拡張の場合に RESTful API のベスト プラクティスに合わせるため、トランジションの名前をどのように処理すればよいかわかりません。
たとえば、特定の顧客のすべての注文を取得する場合、URI は次のようになりhttps://api.website.com/customers/1000/orders
ます。
単一のリソース、つまり顧客または注文に対してトランジションを安静にすることはできますが (Moqui のサンプル アプリ ファイルで示されているように)、リソース拡張の目的を解決する例を見つけることができませんでした。
私が直面している問題は、安らかな API のベスト プラクティスに従って遷移を設計するときです。ExampleApp.xml には、単一のリソース、つまりサンプル エンティティの例しかありません。
プロジェクト管理に関して HiveMind で使用されるデータ モデルの場合、URI はベスト プラクティスに従って次のようになります。
For fetching all Projects- https://api.website.com/projects
For fetching a Milestone for a particular Project - https://api.website.com/projects/DP/milestones/DP-MS-01 (Here, DP is the Project Id)
For fetching a Tasks of a particular Project- https://api.website.com/projects/DP/tasks/DP-1
MoquiフレームワークでAPIを設計している場合、URIに名前を付ける方法は次のとおりです
For fetching all Projects- https://api.website.com/projects
For fetching a Milestone of a Project- https://api.website.com/projects/DP/DP-MS-1
For fetching a Task of a Project- https://api.website.com/projects/DP/DP-1
マイルストーンをフェッチするための URI とタスクをフェッチするための URI を区別できないため、これらの URI が紛らわしいことがわかります。
パス パラメーターをチェックすることで、安らかな API 設計のベスト プラクティスに従って URI を作成することもできます (つまり、パス パラメーターにタスクが含まれている場合は、タスク関連の操作を実行し、マイルストーンについても同様です)。しかし、このアプローチはきれいなものではありません。なぜなら、URI のパラメーターがhttps://api.website.com/projects/DP/milestones/DP-MS-1/tasks/DP-1/worklogs/DP-1-WL-2/party
.
これは、特定のプロジェクトの特定のマイルストーンでタスクの作業ログを追加したパーティ/人物を取得したいシナリオの例にすぎません。これは、1 つのデータ モデル、つまり WorkEffort の場合です。
しかし、パーティー、顧客、注文、製品などのデータモデルはどうでしょうか? API の設計は、API の開発者にとって非常に退屈な仕事になります。
だから私は、参照として使用できるMoquiに実装されている別のよりクリーンなアプローチがあるかどうかを尋ねていましたか?