web-dev-qa-db-ja.com

REST POSTメソッド設計：クエリ/フォームパラメータとコンテンツメッセージのカプセル化

私はRESTAPIを設計していて、クエリ文字列またはコンテンツパラメーターを介して自由形式のパラメーターを吸収するためにPOSTメソッドをフォーマットするという選択肢に直面しています。

POST /my/api HTTP/1.0

paramOne=XYZ&paramTwo=ABC

または、パラメータをカプセル化する厳密にフォーマットされたデータメッセージ（XML/JSON）がポストされることを期待します。

POST /my/api HTTP/1.0

<requestClass>
    <paramOne>XYZ</paramOne>
    <paramTwo>ABC</paramTwo>
</requestClass>

2番目のアプローチを好むのは、それがよりクリーン（単一のコードレベルの入力引数と複数の引数、および基本的な形式の検証を意味する）であり、データ階層にも対応するためです（たとえば、paramTwoにsubエンティティは、不可能ではありませんが、クエリ/フォームパラメータアプローチで実装するにはそれほどクリーンではありません）。

<requestClass>
    <paramOne>XYZ</paramOne>
    <paramTwo>
        <subOne>1</subOne>
        <subTwo>2</subTwo>
    </paramTwo>
</requestClass>

したがって、私の質問は、スタイリングの設定以外に、REST POSTメソッドがパラメータを取るか、単一のカプセル化メッセージを取る必要があるかを決定する際に他の考慮事項がありますか？ ？さまざまな要因または環境に応じて実装するアプローチの基本的なガイドラインはありますか？たとえば、1つのアプローチは他よりもセキュリティの脆弱性を示します（コンテンツとクエリ文字列の両方を使用できるため、実際にはそうではありません）同様に簡単に探知し、HTTPSの場合は問題ありません）など？

それが重要であれば、私のサービスはJavaで記述され、Apache CXFで実行されているTomcat 7を介して提供されます。

designrestapi
2
amphibient

2つの間に1つの具体的な違いがあります。

クエリ文字列の長さは、a POSTリクエストの最大サイズと比較して、（使用しているブラウザ/サーバーに応じて）厳しく制限されています

8000文字は多くのように見えるかもしれませんが、長いパラメーター名を持つもののリストを送信している場合は、すぐに不足する可能性があります。

パラメータの数と最大長を定義していない限り、リクエストの本文を使用する必要があります

1
Ewan

おそらく、最初のオプションを自由形式として記述しないでください。 application/x-www-form-urlencoded エンコーディングを使用してデータを送信するようにクライアントに指示できるようです。これは、フォームを送信するときにWebブラウザが使用するエンコーディングです。

これとXML、JSONなどの他のエンコーディングはどちらもうまく機能するので、確実に実装して明確に文書化するのに最も便利と思われる方を選択します。あなたが言うように、XMLとJSONは通常、ツリー構造のデータに対してform-urlencodedよりもうまく機能します。

どちらかのエンコーディングをコードへの単一の入力として扱うことができるはずです。あなたはあなたが使っているプログラミング言語を言っていませんが、ウェブ上で使われているどんな言語にもリクエストボディを文字列として取得する方法があると思います。送られた。

1
bdsl

POSTとGETの両方をより広く検討することをお勧めします。特にRESTを検討しているため、APIの一貫性に注意してください。

ボディがないため、GETに必要な情報（リソース）のさまざまな識別子は、パスまたはクエリパラメータのいずれかに必ず入ります。

同じパラメーターの場合、GETの場合と同じようにPOSTを実行するので、URIは同じです。 GETとPOSTの間で共有されていない他のパラメーターはどちらの方向にも行く可能性があり、おそらくURIではなく本文で問題ありません。

1
Erik Eidt