web-dev-qa-db-ja.com

REST APIリクエストで多くのIDとその変数名を指定する方法は?

APIリクエストで多くのエンティティのIDを指定する最も一般的で賢明な方法は何ですか?

単一のエンティティリクエストの場合:

GET /v1/entities/{entity_id}

多くのエンティティをリクエストするための私の提案:

GET /v1/entities?entity_ids={entity_id1},{entity_id2}

同じ変数名entity_idを使用:

GET /v1/entities?entity_id={entity_id1},{entity_id2}

単一のエンドポイントの場合、次のようになります。

GET /v1/entities/{entity_id1},{entity_id2}

または、そのようなエンドポイント用に設計する他の方法はありますか?

5
Yann

私が行うべき標準的なことは、RESTを使用してこのような複数のIDを検索しないことです。複数の特定のエンティティをIDでロードしている場合は、なぜそうしているのかを自問する必要があります。おそらく、これらのエンティティは特定の顧客に属する顧客の注文であり、各注文の詳細をロードしています。その場合は、/customer/{id}/ordersのようなURLが必要です。このIDは、事前にIDを認識して個別にロードするのではなく、ID {id}の顧客に属するすべての注文を返します。

それ以外の場合、ユーザーがリストから複数のエンティティをロードして詳細を表示しようとしている場合は、表示を簡略化して一度に1つのエンティティの詳細を表示し、ユーザーが前後に移動するたびにそれぞれのエンティティをロードします。言い換えれば、RESTを呼び出す方法が必要なエンティティ間の明確なリンクがなく、IDによって読み込まれた複数のエンティティが特に必要になる状況にあるべきではありません。個々のIDがリストされたサービス。

11
Neil

これらすべてのアプローチは同じ問題を共有します。多くのIDが照会されると、要求文字列が膨らみます。多くのIDが要求される場合は、クエリ文字列が制限(通常は約2000文字)を超えているため、ゲートウェイサーバーが要求を拒否する可能性があります。

そのことを念頭に置いて、これらのオプションはどれも他のものより賢明ではありません。

他のAPIを見たことがないのに、いくつかのAPIで最後のアプローチを見てきました。一緒に行くことをお勧めします

/entities/id1,id2

補足:RESTfulになりたい場合は、URLを介してAPIバージョン管理を行わないでください。 Entity#5は、アクセスするAPIのバージョンに関係なく、Entity#5のままです。コンセンサスはバージョン管理にヘッダーを使用することです:

X-API-Version: 1
0
marstato