4

私が取り組んでいる農場の動物管理システムと連携するために、REST っぽいベースの Web サービスを設計しようとしています。

問題を詳しく説明するために、農場に属する動物のコレクションがあります。各動物には、名前、ID 番号、品種の年齢などの独自の情報があります。したがって、次のような URI が適していると思います。

/animals               <- retrieve list of animals
/animals/{animal-id}   <- Retrieve only one animal
/animals?breed=sheep   <- Search/query

他の依存リソースを各動物にリンクしようとすると、問題が発生します。動物は、体重情報のコレクションと、私がコメント(特定の動物に対して行われた観察)と呼ぶものを持つことができます。これらはそれぞれ依存しており、その特定の動物にのみ存在しますが、それ自体が私がアクセスしたいリソースです.

IMO で最も簡単な方法は、動物の URI 内にリソースをネストすることです。

/animals/{animal-id}/weights
/animals/{animal-id}/comments

ただし、動物を参照せずに、重みとコメントに直接アクセスしてクエリを実行する必要があると思います。使用例としては、特定の品種のすべての動物から最新の (またはすべての) 体重を取得したり...?breed=sheep、個々の動物 ID の選択に対して体重/コメントを返すこともできます...?animals={ID1},{ID2},{...}。

一度に複数の動物に 1 つのコメントを追加したい場合は、さらに複雑になります。（POSTとJSONの私の表現を許してください）

POST ....
{
  "comment":"Animal moved to paddock B",
  "animals":[{id1}, {id2}, ...]
}

この問題の明らかな解決策は、取得/編集したい各動物に対して (たとえば) GET および POST することであることを理解しています。ただし、最終的にはこのサービスにモバイル デバイスからアクセスする必要があるため、これは避けたいと考えています。そのため、呼び出しの数を減らすことが賢明だと思われます。

Web 標準では URI で CSV が許可されているため、このようなものが機能する可能性があると思います。

/animals/{id1},{id2},{..}/weights

しかし、一度に 10 匹の動物を参照 (または照会) する必要があり、それが乱雑で不親切な URI につながる可能性があると予想しています。

私が現在認識している解決策は、重みとコメントを独自のリソースとして公開することです。これにより、それらに直接アクセスしてクエリできるようになります

/weights
/weights/{weight-id}
/weights?breed=sheep

コレクションに直接投稿することもできます

POST /comments
{
  "comment":"Animal moved to paddock B",
  "animals":[{id1}, {id2}, ...]
}

しかし、何が/animals/{animal-id}/weights返されるでしょうか？それは必要ですか、それとも/weights?animal={animal-id}リソース自体へのリンクを参照するだけですか? しかし、照会されたリソースにリンクしても問題ないでしょうか?

情報にアクセスするための「別の」方法を提供しているだけですか?

データベースがサービス モデルに影響を与えているのでしょうか、それとも要点を完全に見逃しているのでしょうか?

私はこれにまったく慣れておらず、これらの問題に関してかなりの数の矛盾する議論を読んだので、私の要件に何が最適かについて非常に混乱しています.

ありがとう！

4

2 に答える 2

3

/weights他のエンティティ ( など)に対処する場合は、他のエンティティの最上位リソースを定義することをお勧めします/comments。その後、バッチ方式でそれらのエンドポイントに POST できます。

POST /comments

{
    "animals" : [
        {"id" : 1},
        {"id" : 2},
        {"id" : 3},
        {"id" : 4},
    ],
    "commentText" : "Sent to Hamburger Hamlet"
}

URL に ID の長いリストを含めることは、いくつかの理由で適切な設計ではないことに注意してください。たとえば、ほとんどのブラウザーや HTML プロキシには URL の長さに制限があるためです (経験則として、URL の長さを 2083 文字以下に抑えるようにしてください)。 ）。

于 2012-12-12T01:47:11.080 に答える
1

私はあなたと同様の問題を抱えていましたが、最終的には、API を使用してさまざまなユーザー タイプに特定の URL 名前空間 (いわば) を設定することで、複雑さを解消することができました。

たとえば、説明している /weights、/comments アクション (POST、PUT、DELETE など) を実行するファーム ワーカー クライアント アプリである可能性があるため、次のような方法でそれらの機能をクリーンに保つことができます。

/farmworkers/comments
/farmworkers/weights

そして、/animals/{animal-id}/weightsURLを他の「名前空間」内に保持します。

考慮すべきもう 1 つのことは、HAL 形式 (http://stateless.co/hal_specification.html) などを使用してリソースを埋め込むことです。これにより、リクエスト内に複数の動物リソースを埋め込むことができます。これが役立つことを願っています。

于 2012-12-13T00:46:09.383 に答える