3

しばらくの間、私は (誤って) RESTful API が CRUD 操作を Web アプリケーションの永続エンティティに公開しただけだと考えていました。「現実の世界」で何かをコーディングすると、それだけでは不十分であることがすぐにわかります。たとえば、銀行口座振替は永続エンティティである必要はありません。これは、ペイロードで詳細を指定するPOST一時的なリソースである可能性があります。/transfers/

{"accountToCredit":1234, "accountToDebit":5678, "amount":10}

サーバーの状態を変更するため、ここで使用POSTすることは理にかなっています (これが発生するたびに、10 ドルが 1 つのアカウントから別のアカウントに移動しPOSTます)。

サーバーに影響がない場合はどうすればよいですか? 簡単な最初の答えは、 を使用することGETです。たとえば、$100 未満の普通預金口座と当座預金口座のリストを取得するとします。GET次に、 toのようなものを呼び出します/accounts/searchResults?minBalance=0&maxBalance=100。GETただし、リクエストの最大長に収まらない複雑なオブジェクトを検索パラメーターで使用する必要がある場合はどうなりますか。

私の最初の考えは を使用することでしたがPOST、もう少し考えた後PUT、サーバーの状態を変更していないため、おそらく である必要がありますが、私の（限られた）理解から、私は常にPUTリソースを更新しPOST、リソース (この検索結果の作成など)。この場合、どちらを使用する必要がありますか？

いくつかの情報を提供する次のリンクを見つけましたが、さまざまな場合に何を使用すべきかが明確ではありませんでした。

一時的な REST 表現

RESTful な検索/フィルタリングを設計するには?

検索用の RESTful URL 設計

4

1 に答える 1

2

私はあなたのアプローチに同意します.GETリソースを検索するときに使用するのは合理的だと思います.提供されたリンクの1つで述べたように、クエリ文字列の要点は search . また、冪等の方法でリソースを更新したい場合にも、その方が適していることに同意しPUTます (リクエストを何回実行しても、結果は同じになります)。

ですから、一般的には、あなたが提案したとおりにします。GETここで、リクエストの最大長に制限されている場合は、POSTorを使用PUTして、パラメーターを JSON で渡し、次のような URI で指定できます。

PUT /api/search

これは、新しいパラメーターを送信する「検索リソース」と見なすことができます。回避策のように思えますが、REST が URI 内の動詞を回避することを心配しているかもしれません。たとえば、結果を生成するために計算または変換が必要な場合など、動詞を使用することが依然として受け入れられ、RESTful であるケースはほとんどありません (詳細については、このリファレンスを確認してください)。

PS。この回避策は依然として RESTful だと思いますが、そうでなかったとしても、REST は強迫観念や最終目標ではありません。RESTful ではない場合がほとんどだとしても、実用的でクリーンな API 設計を維持することがより良いアプローチになる可能性があります。

于 2013-05-13T21:55:02.437 に答える