2

ビジネスシステム用の残りの API を開発しています。これまでのところ、次のリソースがあります。

/sales/orders
/sales/orders/{orderno}
/sales/order-items

API が完成すると多くのリソースが存在するため、理解しやすいように適切に構成する必要があります。私の質問は次のとおり/sales/order-itemsです/sales/orders/order-items。ここに正解はないかもしれませんが、あなたはどちらを選びますか?

もう 1 つの質問:sales/order-itemsリソースには、すべてのオープン アイテムまたはすべての発送済みアイテムのいずれかが表示されます。ステータス（開封済み/発送済み）に関係なく、すべての注文商品を入手することはできません。リソース URI は次のようにすることもsales/order-items?orderstatus={OPEN/SHIPPED}(orderstatus クエリ パラメータは必須sales/order-items/openになります)、またはこのとのような 2 つのリソースにすることもできますsales/order-items/shipped。好ましいものは何ですか？

4

1 に答える 1

1

リソースとは、「名前を付けることができるすべての情報」です。URI はエンティティ ベースである必要があります。'order-items' はエンティティではなく、データ型です。

/sales/order/order-1456321最も可能性が高いエンティティです。これには、すべての注文項目のデータが含まれます。

アクセスを制限したい場合は、クエリ文字列が指定されていない場合にクライアント エラーを返すことができます。そして持っている

/sales/order/order-12345?status=open

など。これが役立つことを願っています。

編集：

/sales/order-items or /sales/orders/order-items?

これはドメイン固有のものであり、実際にはドメインの専門家が回答する必要があります。URI 階層は、リソースにスコープ (および詳細) を提供します。したがって、経験に基づいた推測として、「注文アイテム」は「注文」ではないため、「/sales/orders/」の範囲内に「注文アイテム」を含めることは意味がありません。

/sales/ordered-items

最も賢明な答えのようです。

個人的な注意として、ドメインについてあまり疑問を抱かないでください。ビジネスの流れと保存されている情報を深く理解することで、これらの提案に沿った結果が得られる可能性があります。

/sales/orders?status=open - Are all orders shipped at once?
/sales/orders/order-1234/packages?status=open - Are orders split into packages?
于 2012-09-26T14:32:40.517 に答える