2

backbone.js から php のコンテキストで、REST API を調査/作成しています。

HTTP 動詞の概念と、それらをいつ使用する必要があるかを理解しています

GET - select

POST - create

PUT - update

DELETE - delete

また、識別子をセマンティックURLとして渡すという概念も理解しています。

GET http://api/users/123

DELETE http://api/users/123

これらの場合、「123」は、ビジネス ロジックがユーザーの取得/削除に使用する ID です。

しかし、POST および PUT コンテキストはどうでしょうか? にリクエストを送るとき

PUT http://api/users/123

APIは、提供されたパラメーターでユーザーID 123を更新します。ここで私の質問が発生します。

更新する入力パラメーターが PUT パラメーターとして送信されると想定します。PHP 構文では、これは次のように表されます: file_get_contents('php://input')(これは削除リクエストでも同じです。)

これを backbone.js でテストすると、完全に機能します。

しかし、新しい要素を作成しようとすると

POST http://api/users/

入力値が POST パラメータとして送信されると仮定します。php 構文では、これは として表され$_POSTます。しかし、これは機能しません。

いくつかのテストを行い、Rails スタイルの REST API (バックボーン ドキュメントが示唆するもの) を読んだ後、すべてのリクエスト変数が同じ方法で送信されることに気付きました。file_get_contents('php://input')すべてのリクエスト タイプのリクエスト パラメータを取得するために使用するコードを変更すると、バックボーンは完全に機能します。

この標準は REST API にとって適切ですか? それとも「レールフレーバー」のものですか？

4

1 に答える 1

1

PUT、POST、PATCH など (GET と DELETE* を除くすべて) は、要求本文を受け入れます。通常、データは次のいずれかとして渡されます。

  • サーバーによってデコードおよび解析される名前/値のペアの URL エンコード文字列 (URL クエリ文字列とまったく同じ$_POST)。これは通常、に設定されたヘッダーの存在に依存しContent-Typeapplication/x-www-form-urlencodedます (ブラウザーは、フォームが送信されるときにデフォルトでこれを行います)。データが表示されているのに表示されてfile_get_contents('php://input')いない$_POST場合は、このヘッダーが存在しないか、別の値に設定されている可能性が非常に高くなります。Chrome を使用している場合、クライアントが送信しているヘッダーと本文は、開発ツールの [ネットワーク] タブで確認できます。

  • もう 1 つの一般的な要求本文の形式はContent-Type: application/json、JSON 文字列を使用して本文に書き出すことです。これは、JSON パーサーを介してアクセスしfile_get_contents('php://input')、解析することができます。

* DELETE に関する注意: DELETEでのリクエスト ボディの使用が許可されているかどうか、または適切なプラクティスであるかどうかは、少し不明です。

于 2013-08-01T20:43:03.657 に答える