6

名前と複数の場所（/ users / {id} / location）を持つユーザー（/ users / {id}）について考えてみます。

ユーザー（/ user / {id}）をリクエストするとき、そのユーザーを完全に表す必要がありますか（ID、名前、場所）、または場所は別のリクエストでのみ返される必要がありますか？たとえば、id = 123（/ users / 123）のユーザーのリクエストでどのJSONDTOを期待しますか。

1）{"id"：123、 "name"： "Peter"、 "locations"：[{"id"：1、 "name"： "Chicago"}、{"id"：2、 "name"： "ニューヨーク"}] }

2）{"id"：123、 "name"： "Peter"、 "locations"：[{"id"：1}、{"id"：2}]}

3）{"id"：123、 "name"： "Peter"、 "locations"：[1、2]}

4）{"id"：123、 "name"： "Peter"}

これは、より主観的なものであり、DTOのサイズと、一般的なユースケースで必要とされる要求との間でプッシュおよびプルしますか？関連するすべてのデータ（1）を単純に含める傾向がありますが、実際に必要なすべてのデータを取得するために、開発者がAPIを複数回呼び出す必要があるよりも優れているかどうかはわかりません。

4

3 に答える 3

3

RESTfulであるために、必ずしもリソースの完全な表現を返す必要はありません。ただし、APIのユーザーが必要とするすべての情報を取得/設定する手段としてハイパーメディアを有効にする必要があります（アプリケーション状態のエンジンとしてのハイパーメディア-別名HATEOAS）。

これを満足させるには、@ bowmanbによる提案を使用して、すべての場所のURIを配置するか、場所ごとに個別のURIを追加します。リソースを使って何かをする他のオプションのために、URIを追加したいと思うかもしれません。

ジム・ウェッバー、サバス・パラスタティディス、イアン・ロビンソンによるHATEOASに関する良い記事があり、「コーヒーを飲む方法」と呼ばれています。

于 2012-05-02T12:30:47.907 に答える
2

私はこの世界の初心者ですが、安らかなAPIを構築しており、まったく同じ問題に直面しています。私の最初の仕事はすべてを含めることでした-それで私の結果はあなたのオプションのように見えます（1）。実際、私はもう少し進んで、各オブジェクトにURIを含めたので、理論的には、十分にインテリジェントなクライアントが応答をナビゲートできます。

そうは言っても、あなたの「ユーザー」オブジェクトに相当する私の特定の属性の1つが巨大であることがわかりました。パフォーマンスに影響を与えるようには見えませんが、特定の属性に関するすべての情報を必要とするクライアントはいないようです。ほとんどのクライアントは、IDと名前だけを必要とします。そのため、その属性のデフォルトのアプローチを変更します。

結論として、私の初心者の意見では、決定はクライアントの予想される使用法によって決定されるということです。クライアントは何を見たいと思いますか？

于 2012-05-02T00:48:30.460 に答える
1

クライアントがユーザーの場所を見つける方法を決定するための何らかの方法があるはずです。だから私は4番を除外します。

応答のサイズが心配な場合でも、ユーザーの場所へのURIだけを含めるのはRESTfulだと思います。

{ "id":123, "name":"Peter", "locations":"/users/123/locations" }
于 2012-05-02T04:15:21.287 に答える