Delicious APIを調べていると、新しいブックマークを作成する操作は次のようになります。
https://api.del.icio.us/v1/posts/add?&url={URL}&description={description}
彼らはGETリクエストを使用してサーバー側のデータベースエントリを作成しているようですが、他の場所で読んだことがありますが、GETリクエストでは実行せず、POSTリクエストでのみ実行する必要があります。
私は今自分のAPIを書いていますが、ユーザーがURLから直接APIを操作できるようにするのは素晴らしいことだと思います。ただし、GETを介したCRUD操作を許可しない限り、これを行うことはできません。
では、Deliciousは本当にGETを介してCRUD操作を行っているのでしょうか？APIで同じことをすべきではないという重要な理由がありますか、それとも偶発的な呼び出しを防ぐためにPOSTがCRUDに義務付けられているだけですか？
それは、RESTの原則に従うかどうかによって異なります。変更するためのGETは禁止されています。したがって、ほとんどの人は、RESTでは変更にPOSTを使用すると言います。
ただし、GETとPOSTには違いがあります。RFCによると、GETリクエストには常にフォローアップRESPONSEがあります。また、POSTを使用する場合は、Redirect-After-Postパターンに従う必要があります。
もう1つの制限は、URLのサイズが制限されている可能性があることです。したがって、GETは、入力データが十分に短い場合にのみ機能します。したがって、おいしいAPIにはバグがあります。GETパラメータを介してすべての可能なURLを追加することはできません。
偶発的な呼び出しはその一部です。これが、「べき等」メソッドについて説明するHTTP仕様の意味です。しかし、何度GETしても、URLが1回だけ追加される限り、Deliciousが行っていることは実際にはべき等であると主張することができます。しかし、もっと重要なのは、GETが安全であるということです。
The important distinction here is that the user
did not request the side-effects, so therefore
cannot be held accountable for them.
インターフェイス設計の観点から、ユーザーエージェントがPOST、PUT、およびDELETEをGETよりも難しくするか、少なくとも明確に異なるようにして、ユーザーがその違いに基づいて、アクションによってリソースの状態が変化する可能性があることを示唆できるようにします。 、それらの変更に責任があるためです。GETを使用して変更を加えると、たとえべき等であっても、特にプリフェッチャーが広く展開されている場合は、その説明責任の線が曖昧になります。