Google や SO を検索すればするほど、RESTful なネーミングは標準というより黒魔術のように思えます。私が持っているシナリオと現在の考え方を説明し、REST の経験がある方に意見を求めたいと思います。
物理フォルダーまたはバインダーと考えることができる「パケット」オブジェクトがあります。このパケットの中には、1 つまたは複数のフォームがあります。私のシステムでは、これらを PacketForms というリソースとして表しています。各フォーム レコードには、フォームが表示/印刷される順序を定義する SortIndex 列があります。
アプリケーションでフォームのリストを表示すると、ユーザーがフォームの SortIndex を変更できる上向き/下向きの矢印があります。これで、このアクションを実装する準備が整いました。
私の最初の考えは、ソート順でフォームを昇格/降格するための特別な操作を持つことでした。このアプローチを採用する場合、ここで見たことに基づいて、ソート インデックス自体をリソースと考える必要があるようです。だから、クエリ文字列で自分の意図を表現できますよね？
PUT /PacketFormSortIndex/5?action=昇格
しかし、PacketForm 自体を更新して、バックエンドが SortIndex の変更を検索できるようにしない理由も考えました。昇格/降格のアプローチではなく、SortIndex が変更された場合、現在そのインデックスを持つフォームと交換します。したがって、だれかが SortIndex=3 の PacketForm を更新して SortIndex=2 の値を持つようにすると、システムは両方のレコードを更新してスワップを完了します。
個人的には、最初のアプローチのアトミックな性質が気に入っています。非常に具体的で明確な目的があり、バックエンドのコードはよりクリーンです。しかし、そのロジックをシステム全体に広めると、「リソースのスプロール化」について少し心配になります。
それで、私はここで2つの後の質問があると思います. これらのアプローチのうち、どちらがより「RESTy」だと感じますか? それが最初の場合、私が提案した方法でクエリ文字列を使用するのは適切ですか、それともその URL を整理するより RESTful な方法はありますか?
非常に広く使用されているものについては、私が見つけてきた多種多様な情報に本当に苦労しているので、あなたの視点は非常に高く評価されています.