たとえば、ほとんどの MVC フレームワークでは、クエリ文字列パラメーターとフォーム パラメーターの両方が処理コードで使用可能になり、通常は 1 つのパラメーター セットにマージされます (多くの場合、POST が優先されます)。しかし、それはHTTP仕様に従って行うことは有効ですか? 次の宛先に POST するとします。
http://1.2.3.4/MyApplication/Books?bookCode=1234
...そして、書籍コードが 1234 である書籍名の変更などの更新を送信すると、処理コードで、bookCodeクエリ文字列パラメーターと、更新された書籍情報を含む POST フォーム パラメーターの両方を考慮する必要があります。これは有効ですか、それは良い考えですか?
HTTP 仕様に従って有効ですか?
はい。
これらの仕様で定義されている URLの一般的な構文は次のとおりです。
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
http_URL の形式に追加の制約はありません。特に、使用されるhttp メソッド(つまり、POST、GET、PUT、HEAD など) は、http URL 形式に制限を追加しません。
GET メソッドを使用する場合: サーバーはリクエストの本文が空であると見なすことができます。
POST メソッドを使用する場合: サーバーはリクエスト本文を処理する必要があります。
それは良い考えですか？
それはあなたが何をする必要があるかによって異なります。GET と POST の背後にあるアイデアを説明するこのリンクをお勧めします。
状況によっては、URL のクエリ部分にユーザー言語などのパラメーターを常に含めると便利な場合があると思います。
たとえば、ほとんどの MVC フレームワークでは、クエリ文字列パラメーターとフォーム パラメーターの両方が処理コードで使用可能になり、通常は 1 つのパラメーター セットにマージされます (多くの場合、POST が優先されます)。
有能なフレームワークはこれをサポートする必要があります。
これは有効ですか
はい。HTTP の POST メソッドは、使用される URI に制限を課しません。
それは良い考えですか？
使用するフレームワークがまだ手がかりに挑戦している場合は、明らかにそうではありません。それ以外の場合は、何を達成したいかによって異なります。主なユース ケース (データ サブセットの新しい POST ターゲットへのリダイレクト) は、ブラウザーの実装によって取り返しのつかないほど破られています(すべて機械的に Mosaic/Netscape の壊れたリードに従っています)。