API を作成していますが、なぜ PUT の URI に id パラメータを含めるのが一般的なのでしょうか?
なぜPUT /cars/5
持っていないのPUT /carsですか？リクエスト エンティティに id フィールドが含まれているだけでは不十分ですか? そのエンティティからIDを取得できますか、それともこれにはいくつかの欠点がありますか?それを行うのは悪いと考えられていますか?
質問する
83 次
4 に答える
4
PUTにリクエストを送信した場合、意味的には、個々の車の属性を変更するのではなく、車のセット/carsに関する属性を変更しようとしていることを意味します。RESTful API の URI は、アクションが作用する正確なリソースを示す必要があるため、リソースを変更する場合、URI はそのリソースを正確に示す必要があります。
また、RFC 2616から:
PUT リクエストの URI は、リクエストに含まれるエンティティを識別します。ユーザー エージェントは、意図されている URI を認識しており、サーバーはリクエストを他のリソースに適用しようとしてはなりません (MUST NOT)。
そのため、仕様は、クライアントがリソースの一意の ID を知っている場合、それを URI に含める必要があることを示しています。
于 2013-04-21T17:48:49.847 に答える
2
PUT1 つの正確なエンティティを更新することを目的としています。
を使用するだけ/carsでは、特定のエンティティに焦点を当てていません。
そして、あなたが書いたこととは反対に、完全なエンティティは基本的な文字列 (URI) で渡されません。
対象となるメソッドがハードコードされたものに焦点を当てている場合は例外ですcar id...しかし、私はそうは思いません..
于 2013-04-21T17:46:35.927 に答える
2
これは残りの「イデオロギー」から来ています。
アイデアは、URL がエンティティを一意に表すということです。そのため、作成/編集しているエンティティをそのエンティティの URL に PUT する必要があります。
ウィキペディアのページから引用するには：
リソースの識別
個々のリソースは、たとえば Web ベースの REST システムで URI を使用して、リクエストで識別されます。リソース自体は、クライアントに返される表現とは概念的に分離されています。
于 2013-04-21T17:44:11.587 に答える
2
それはAPIインターフェースに帰着します。API 設計にはいくつかのアプローチがあります。そして、あなたが提案したように、リクエストからIDを除外できます。ただし、多くの API 設計は、PUT /cars/5 のように、あなたが説明した方法で構造化されているため、良い習慣と見なされます。
基本的に、API を操作するには 8 つの方法があります。GET、POST、PUT、DELETE、およびオプションの HEAD。(頭を数える場合、相互作用に応じて、合計は 9 または 10 になります)。
したがって、それを明確にするために、GET には 2 つの方法があります。GET /cars はすべての車を取得し、GET /cars/5 は ID が 5 の任意の車を取得します。したがって、GET を使用するには 2 つの方法があります。POST、PUT、DELETE についても同様です。4*2 = 8 ですよね？
さて、PUT /cars はあいまいだと言う人がいますが、追加の ID フィールドなしでそれを行うことは完全に有効です。
Apigee の担当者は、しばらくの間 API の設計を研究してきました。API の設計が何を意味するのか、また、一部の引数が有効で他の引数が無効である理由をよりよく理解するために、いくつかのビデオを視聴することをお勧めします。
于 2013-04-21T17:49:20.470 に答える