321

ここですでに尋ねられている質問はしていません: @PathParam と @QueryParam の違いは何ですか

これは、「ベスト プラクティス」または規約に関する質問です。

いつ@PathParamvsを使いますか@QueryParam。

私が考えることができる決定は、情報パターンを区別するために2つを使用している可能性があります. 以下の LTPO を説明しましょう - 完璧な観察とは言えません。

PathParam の使用は、情報ツリーのブランチに適切に分類される情報カテゴリ用に予約できます。PathParam を使用して、エンティティ クラス階層にドリルダウンできます。

一方、QueryParam は、クラスのインスタンスを見つけるための属性を指定するために予約できます。

例えば、

  • /Vehicle/Car?registration=123
  • /House/Colonial?region=newengland

/category?instance

@GET
@Path("/employee/{dept}")
Patient getEmployee(@PathParam("dept")Long dept, @QueryParam("id")Long id) ;

対/category/instance

@GET
@Path("/employee/{dept}/{id}")
Patient getEmployee(@PathParam("dept")Long dept, @PathParam("id")Long id) ;

対?category+instance

@GET
@Path("/employee")
Patient getEmployee(@QueryParam("dept")Long dept, @QueryParam("id")Long id) ;

それを行う標準的な慣習はないと思います。ある？ただし、上記で例示したように、人々が PathParam と QueryParam を使用して情報を区別する方法について聞きたいと思います。また、施術の理由もお聞きしたいです。

4

17 に答える 17

294

REST 自体は標準ではないかもしれませんが、REST の一般的なドキュメントやブログ投稿を読むと、API URL を構成するための適切な方法に関するガイドラインが得られるはずです。ほとんどの残りの API は、パスにリソース名とリソース ID のみを持つ傾向があります。そのような：

/departments/{dept}/employees/{id}

一部の REST API は、フィルタリング、ページネーション、および並べ替えにクエリ文字列を使用しますが、REST は厳密な標準ではないため、 githubやstackoverflowなどのいくつかの REST API をチェックして、ユース ケースに適したものを確認することをお勧めします。

必要なパラメーターはすべてパスに入れることをお勧めします。また、オプションのパラメーターは必ずクエリ文字列パラメーターにする必要があります。オプションのパラメーターをパスに入れると、さまざまな組み合わせに一致する URL ハンドラーを作成しようとすると、非常に面倒になります。

于 2012-07-19T20:49:24.180 に答える
106

これが私がすることです。

ID に基づいてレコードを取得するシナリオがある場合、たとえば、ID が 15 の従業員の詳細を取得する必要がある場合、@PathParam でリソースを取得できます。

GET /employee/{id}

すべての従業員の詳細を取得する必要があるが、一度に 10 人だけを取得する必要があるシナリオがある場合は、クエリ パラメータを使用できます。

GET /employee?start=1&size=10

これは、最初の従業員 ID 1 が 10 個のレコードを取得することを示しています。

要約すると、id に基づく取得には @PathParam を使用します。フィルター用のユーザー @QueryParam、またはユーザーが渡すことができるオプションの固定リストがある場合。

于 2012-07-19T01:14:10.353 に答える
49

パラメータが特定のエンティティを識別する場合は、パス変数を使用する必要があると思います。たとえば、リクエストしたブログのすべての投稿を取得するには

GET: myserver.com/myblog/posts

ID = 123 の投稿を取得するには、リクエストします

GET: myserver.com/myblog/posts/123

しかし、投稿のリストをフィルタリングして、2013 年 1 月 1 日以降のすべての投稿を取得するには、次のようにリクエストします。

GET: myserver.com/myblog/posts?since=2013-01-01

最初の例の「投稿」は、特定のエンティティ (ブログ投稿のコレクション全体) を識別します。2 番目の例では、「123」も特定のエンティティ (単一のブログ投稿) を表します。ただし、最後の例では、パラメーター「since=2013-01-01」は、特定のエンティティではなく、投稿コレクションをフィルター処理するための要求です。ページネーションと順序付けは、別の良い例です。

GET: myserver.com/myblog/posts?page=2&order=backward

それが役立つことを願っています。:-)

于 2013-04-03T14:00:25.337 に答える
9

私は個人的に、「ユーザーがこれらのパラメーターを含む URL をブックマークすることが理にかなっている場合は、PathParam を使用する」というアプローチを使用しました。

たとえば、ユーザー プロファイルの URL にプロファイル ID パラメーターが含まれている場合、これはユーザーがブックマークしたり、メールで送信したりできるため、そのプロファイル ID をパス パラメーターとして含めます。また、これに関するもう 1 つの考慮事項は、パス パラメータを含む URL で示されるページが変更されないことです。ユーザーは自分のプロファイルを設定して保存し、そこから大きく変更することはほとんどありません。これは、webcrawlers/search engine/browsers/etc がパスに基づいてこのページを適切にキャッシュできることを意味します。

URL で渡されたパラメーターがページ レイアウト/コンテンツを変更する可能性が高い場合は、それをクエリパラメーターとして使用します。たとえば、プロファイル URL がユーザーの電子メールを表示するかどうかを指定するパラメーターをサポートしている場合、それをクエリ パラメーターと見なします。（間違いなく、&noemail=1またはそれが何であれ、パラメーターはパスパラメーターとして使用でき、2つの別々のページを生成すると言うことができます-1つはメールがあり、もう1つはメールがありません-しかし、論理的にはそうではありません:特定の属性が表示されているかどうかに関係なく、同じページのままです。

これがお役に立てば幸いです - 説明が少し曖昧かもしれません:)

于 2012-07-19T00:35:19.743 に答える
8

フィルター処理にはクエリ パラメーターを使用し、グループ化にはパス パラメーターを使用できます。次のリンクには、pathParams または QueryParams をいつ使用するかに関する適切な情報があります。

于 2012-07-19T00:43:40.127 に答える
6

とても興味深い質問です。

どちらも使用できます。この件に関して厳密な規則はありませんが、URI パス変数を使用するといくつかの利点があります。

  • キャッシュ: インターネット上のほとんどの Web キャッシュ サービスは、クエリ パラメータが含まれている場合、GET 要求をキャッシュしません。サーバー内のデータを変更するためにGETリクエストを使用するRPCシステムがたくさんあるため、彼らはそれを行います（失敗!!Getは安全な方法でなければなりません）

ただし、パス変数を使用すると、このすべてのサービスで GET 要求をキャッシュできます。

  • Hierarchy : パス変数は階層を表すことができます: /City/Street/Place

これにより、データの構造に関する詳細情報がユーザーに提供されます。

ただし、データに階層関係がない場合でも、コンマまたはセミコロンを使用してパス変数を使用できます。

/都市/経度、緯度

原則として、パラメーターの順序が重要な場合はコンマを使用し、順序が重要でない場合はセミコロンを使用します。

/IconGenerator/赤;青;緑

これらの理由とは別に、クエリ文字列変数を使用することが非常に一般的な場合がいくつかあります。

  • ブラウザーが自動的に HTML フォーム変数を URI に入れる必要がある場合
  • アルゴリズムを扱っているとき。たとえば、Google エンジンはクエリ文字列を使用します。

http://www.google.com/search?q=rest

要約すると、この方法のいずれかを使用する強い理由はありませんが、できる限り URI 変数を使用してください。

于 2015-02-13T09:11:39.030 に答える
3

ウィキペディアから: Uniform Resource Locator

データを含むパス。通常は階層形式で編成され、スラッシュで区切られた一連のセグメントとして表示されます。

非階層データのクエリ文字列を含む、前の部分から疑問符 (?) で区切られたオプションの query。

— URL の概念設計に従って、階層データ/ディレクティブ/ロケーター コンポーネントの PathParam を実装するか、データが階層でない場合は QueryParam を実装する場合があります。パスは自然に順序付けられているのに対し、クエリには任意に順序付けできる変数 (順序付けされていない変数/値のペア) が含まれているため、これは理にかなっています。

以前のコメンテーターが書いた、

パラメータが特定のエンティティを識別する場合は、パス変数を使用する必要があると思います。

別の書き込み、

ID に基づく取得には @PathParam を使用します。フィルター用のユーザー @QueryParam、またはユーザーが渡すことができるオプションの固定リストがある場合。

別、

必要なパラメーターをパスに入れることをお勧めします。オプションのパラメーターは、必ずクエリ文字列パラメーターにする必要があります。

— ただし、特定のエンティティを識別するための柔軟で非階層的なシステムを実装することもできます! SQL テーブルに複数の一意のインデックスがあり、一意のインデックスを構成するフィールドの任意の組み合わせを使用してエンティティを識別できる場合があります。さまざまな組み合わせ (おそらく順序も異なる) が、さまざまな関連エンティティ (リファラー) からのリンクに使用される場合があります。この場合、個々のエンティティを識別するために使用される非階層データを扱っている可能性があります。または、特定の変数/フィールド (一意のインデックスの特定のコンポーネント) のみを指定して、レコードのリスト/セットを取得する場合もあります。このような場合、URL を QueryParams として実装する方が簡単で、より論理的で合理的です。

長い 16 進文字列は、パスの残りの部分にあるキーワードの値を薄めたり小さくしたりできますか? 変数/値をパスまたはクエリに配置することの潜在的な SEO への影響を検討する価値があるかもしれません、およびアドレスバーのコンテンツを編集することで、ユーザーが URL の階層をトラバース/探索できるようにするかどうかのヒューマン インターフェイスへの影響。私の 404 Not Found ページは SSI 変数を使用して、壊れた URL を親に自動的にリダイレクトします! 検索ロボットもパス階層をトラバースする場合があります。一方、個人的には、ソーシャル メディアで URL を共有するときは、プライベートな一意の識別子を手動で取り除きます。通常は、URL からクエリを切り捨て、パスのみを残します。この場合、一意の識別子を配置することにはいくつかのユーティリティがあります。クエリではなくパスで。粗いユーザー インターフェイスとしてパス コンポーネントの使用を容易にするかどうかは、おそらく、データ/コンポーネントが人間が判読できるかどうかに依存します。人間が読みやすいかどうかの問題は、階層の問題に多少関連しています。多くの場合、人間が読めるキーワードとして表現できるデータも階層的です。一方、階層データは、人間が読めるキーワードとして表現されることがよくあります。(検索エンジン自体は、ユーザー インターフェイスとしての URL の使用を拡張するものとして定義される場合があります。) キーワードまたはディレクティブの階層は、厳密に順序付けられていない場合がありますが、通常、それらはパス内の代替ケースをカバーできるほど十分に接近しています。1 つのオプションを「標準的な」ケースとしてラベル付けします。

基本的に、各リクエストの URL で回答できる質問にはいくつかの種類があります。

  1. どのような種類のレコード/ものを要求/提供していますか?
  2. 私たちはどれに興味がありますか？
  3. 情報/記録をどのように提示したいですか?

Q1 は、ほぼ確実に、パスまたは PathParams によってカバーされるのが最適です。Q3 (おそらく、任意に並べられたオプションのパラメーターとデフォルト値のセットを介して制御されます); ほとんどの場合、QueryParams でカバーするのが最適です。Q2: 場合による…</p>

于 2016-04-20T17:40:49.903 に答える
2

Theon が指摘したように、REST は標準ではありません。ただし、標準ベースの URI 規則の実装を検討している場合は、oData URI 規則を検討してください。Ver 4 はOASIS 標準として承認されており、 Apache Olingo 経由で Java を含むさまざまな言語の oData 用のライブラリが存在します。Red Hat、Citrix、IBM、Blackberry、Drupal、Netflix、Facebook、SAP など、他の業界関係者からも支持を得ているため、Microsoft から生まれたという事実に惑わされないでください。

その他の採用者はこちらにリストされています

于 2014-05-14T17:10:44.313 に答える
2

PATH PARAMETER - パス パラメーターは、特定のリソースを指すのに役立つ URL パスの変数です。

Example - https://sitename.com/questions/115

ここで、115 がパス パラメータである場合、他の有効な数値に変更して、同じアプリケーションの他のリソースをフェッチ/ポイントすることができます。

クエリ パラメーター - クエリ パラメーターは、リストから特定のリソースをフィルター処理する URL パス内の変数です。

Example - https://sitename.com/questions/115?qp1=val1&qp2=val2&qp3=val3

ここで、qp1、qp2、および qp3 は、値が val1、val2、および val3 であるクエリ変数です。これらは、データの取得/保存中にフィルターとして適用するために使用できます。クエリ変数は常に、疑問符 (?) の後に URL に追加されます。

于 2021-07-23T05:59:30.290 に答える
1

@Queryparamアンダーサンドの例を 1 つ示します。@pathparam

たとえば、私は1つのリソースを取っていますcarResourceクラスです

リソース メソッドの入力を必須にしたい場合は、パラメータ タイプを as として使用し@pathaparamます。リソース メソッドの入力をオプションにする必要がある場合は、そのパラメータ タイプを@QueryParamparamとして保持します。

@Path("/car")
class CarResource
{
    @Get
    @produces("text/plain")
    @Path("/search/{carmodel}")
    public String getCarSearch(@PathParam("carmodel")String model,@QueryParam("carcolor")String color) {
        //logic for getting cars based on carmodel and color
            -----
        return cars
    }
}

このリソースに対して、リクエストを渡します

req uri ://address:2020/carWeb/car/search/swift?carcolor=red

このようにreqを指定すると、リソースはベースの車のモデルと色を提供します

 req uri://address:2020/carWeb/car/search/swift

このように req を指定すると、 resoce メソッドは迅速なモデルベースの車のみを表示します

req://address:2020/carWeb/car/search?carcolor=red

このように指定すると、ResourceNotFound 例外が発生します。これは、車のリソース クラスで carmodel を宣言した@pathPramため、carmodel を reQ uri として指定する必要があるためです。そうしないと、リソースに req が渡されませんが、色を渡さない場合また、色は@quetyParamreqでオプションであるため、reqをresourceに渡します。

于 2014-12-18T12:27:57.310 に答える
1

理由は実はとても簡単です。クエリ パラメーターを使用する場合、"/" などの文字を使用でき、クライアントはそれらを html エンコードする必要はありません。他にも理由はありますが、簡単な例です。パス変数をいつ使用するかについて。IDを扱っているとき、またはパス変数がクエリの方向である場合はいつでも言います。

于 2014-08-27T14:54:42.760 に答える
0
  1. @QueryParamクエリ パラメータが渡されない場合に null ポインタ例外を回避できるように、Default Value アノテーションと一緒に便利に使用できます。

GET リクエストからクエリ パラメータを解析する場合は、GET リクエストを処理するメソッドにそれぞれのパラメータを定義し、アノテーションで@QueryParam注釈を付けることができます。

  1. @PathParamURI 値を抽出し、 に一致し@Pathます。したがって、入力パラメーターを取得します。2.1@PathParamは複数指定でき、メソッドの引数に設定されます

    @Path("/rest")
public class Abc {

    @GET
    @Path("/msg/{p0}/{p1}")
    @Produces("text/plain")
    public String add(@PathParam("p0") Integer param1, @PathParam("p1")  Integer param2 )
    {
        return String.valueOf(param1+param2);
    }
}

上記の例では
http://localhost:8080/Restr/rest/msg/{p0}/{p1}、と が
p0一致し、 がparam1とp1一致しparam2ます。したがって、URI
http://localhost:8080/Restr/rest/msg/4/6について
は結果が得られ10ます。

REST サービスでは、JAX-RS はHTTP リクエストからデータを受け入れるために@QueryParamと両方を提供します。@FormParamHTTP フォームは、GET や POST などのさまざまな方法で送信できます。

@QueryParam: GET リクエストを受け入れ、クエリ文字列からデータを読み取ります。

@FormParam: POST リクエストを受け入れ、HTML フォームまたはメディアの任意のリクエストからデータを取得します

于 2016-01-21T12:03:12.327 に答える