9

MVCパターンとRESTサービスでは、次のようなURIを使用するのが一般的であることを理解してい/items/{id}ますが、URIでクエリパラメーターを使用することの悪い点は何ですか？

GET /items/{id}vsGET /items?id={id}

さらに、エンティティに関連する（親などの）エンティティを指す'referenceId'フィールドがあり、親エンティティのすべてのアイテムを取得するためにRESTサービスを作成する必要があるとします。どちらの方法が良いですか。

GET(POST) /items/parent/{parentId}

また

GET(POST) /items?parent={parentId}

RESTサービスのURLの構築に関する私の主観的な問題を解決するのに役立つ洞察に感謝します。

4

4 に答える 4

6

私は次のスキームを使用します。

/items/id

これは、idを持つアイテムのリソースを一意にアドレス指定しますid。このリソースを一意にアドレス指定するためのパラメーターとしてパラメーターを使用していません（他のオプションの場合のように）。miguelcobainが示唆するように。

/parent/id/items

idこれは、親のリソースを一意にアドレス指定するためのIDであり、それらから参照するアイテムを収集/取得します。質問であなたが言ったことから、親はコンテナやコレクションのような複数のアイテムを参照しているようです。

これに使用する規則は、スコープを左から右に絞り込むことです。したがって、アイテムがまたはである可能性があるactive場合inactive。したがって、アイテムには、またはであるプロパティまたは属性がありactiveますinactive。これを絞り込むと、次のスキームが得られます。

/items/active
/parent/id/active
于 2013-01-15T17:52:01.397 に答える
4

あなたの最初の質問のために：

/items/{id}404指定されたIDを持つ、または存在しない場合は、単一のリソースを取得する必要があります。

/items/?id={id}コレクションをクエリしているため、配列を取得する必要があります（配列内に1つしかない場合でも）。

2番目の質問：

@miguelcobainの評価に同意します。アイテムが特定のリソース/エンティティである場合は、適切なリソースパスを使用して取得します。

コンシューマーでこれを簡単に行うには、リンクヘッダーを作成するrel="parent"か、子リソースにURIを含めます。リンクヘッダーの例については、GitHubのページ付けAPIを参照してください。

于 2013-01-15T18:10:48.173 に答える
2

もちろん、RESTの原則はURLの美的詳細を気にしません。すべてのリソースが一意にアドレス可能である必要があることを強制するだけです。

さらに、クエリパラメータを使用して「種類」の何かに一意に対処することは、「パラメータ」のセマンティクスに違反しますね。パラメータは、オプションであり、追加でパラメータ化されている必要があります。たとえば、アイテムのコレクションの詳細な検索のようなものです。

あなたが書いたことは、場合によっては意味をなすかもしれません。場合によります。

あなたの例では、アイテムは本当にリソースですか？そうでない場合は、あなたはただすることができますGET(POST) /parents/{parentId}。

たとえばparent、ブール値で、親がtrueに等しいアイテムを検索する場合は、パラメーターを使用するのが理にかなっています。ただし、特定のIDを持つ親が必要であると明示的に言っているので、親はリソース自体であると想定し、オプション1を使用してそのリソースに一意にアドレス指定します。

私は自分自身を明確にしたいと思います。

于 2013-01-15T17:38:46.507 に答える
0

従うべきルールはないように私には思えます。

items/{id}-この規則は、指定されたIDによるアイテムのGETに適しています。ユーザーがIDを指定しない場合、404ステータスコードが返されます。

items/id={id}&name={name}-このタイプの規則は、特定の基準で複数のアイテムを検索するのに適しています。アイテムが見つからない場合、それは404の状況ではなく、単に「検索条件に一致するものが何も見つかりませんでした」と言うだけです。

于 2014-10-01T06:52:52.450 に答える