0

オブジェクトの例

これに似たオブジェクト構造を考えると、APIをどのように構造化するのでしょうか。ヘッダーのBookWishlistsには独自のエンドポイントがあり、詳細のWishlistEntriesは個別にフェッチされますか？

また、APIはさまざまなタイプのWishlistEntriesの構造にする必要がありますか？追加するエントリの「タイプ」を受け入れるエンドポイントが1つありますか？（例としてPOST / [EntryType] / [BaseBookId]）エントリのタイプごとに個別のエンドポイントを設定する方がよいですか？（POST / BookOnAmazon / [ BookOnAmazon：Id]）

このようなAPIへのリンクは、見つからなかったため、よろしくお願いします。

必要に応じて、Phonegap/Javascriptフロントエンドを使用してASP.netWebAPIでこれを実行しています。

4

2 に答える 2

0

のサムルールに従うことができます/resources/{particularResourceId}/subresources/{oneSubresourceId}

したがって、書籍に直接アクセスする予定がない場合は、主なリソースを 1 つだけ考えます。

/wishlists/ Amazon ウィッシュリスト エントリ内のすべての書籍のすべてのウィッシュリスト エントリの
/wishlists/{listId}1 つの特定のウィッシュリストを取得するためのウィッシュリストのリストを取得するため。
/wishlists/{listId}/entries/
/wishlists/{listId}/entries/amazon/books

頭の中で形成された URL を論理的に取得します。

于 2012-09-15T10:36:00.407 に答える
0

各「リソース」はエンドポイントであり、ウィッシュリストの URL 構造は問題ないように見えます。

データベース テーブルをリソースに直接マッピングすることが常に正しいことだとは思いません。API の消費者の考え方に身を置く方がよいでしょう。彼らは何を求める必要がありますか？

リソースが 2 つしかないように見えます

  • ウィッシュリスト
  • 本

本は実際にはウィッシュリストの一部です。ウィッシュリストのエントリ、または消費者が要求できる ID だけですべての書籍の詳細を返したい場合とそうでない場合があります。後者は、消費者によるより多くの開発努力/要求を必要としますが、おそらくより効率的です。

于 2012-09-14T21:51:01.273 に答える