我必须在现有产品数据库的顶部放置一个（只读）REST服务。简单的部分是拥有顶级产品资源，例如：
/api/products/
现在，实际上这项服务的来电者需要根据商店的ID和特定流程（例如＆＃34;零售＆＃34;）来获取相关产品。在幕后，这两个值的组合产生了配置的产品子集。这对于呼叫者来说必须是透明的，它不应该知道这些＆＃34;产品组合＆＃34;。
所以我考虑过像这样设计URI，其中1234是StoreID，零售就是这个过程：
/api/stores/1234/retail/products
这里提出的第一个问题是，我应该在这里返回完整的产品，还是在/ api / products /上将各个资源的URI归还给他们......专业人员显然不需要从中检索每个产品/ api / products，这将导致/ api / stores / 1234 / retail / products URI上的缓存问题。
为了使事情变得复杂，那些产品当然也有价格。此外，除了其他因素之外，产品没有一个价格，但多个也依赖于StoreID和Process。实际上，价格是产品的直接子女，所以：
/api/products/ABCD/prices
将是显而易见的选择，但同样，由于StoreID和Process与预过滤价格相关，因此如下所示：
/api/stores/1234/retail/products/ABCD/prices
会更合适。
与此同时，还有其他产品子资源在此URI下没有意义，例如产品详细信息。这些显然只在/ api / products / ABCD / details下直接有意义，因为它们不依赖于商店或流程。
但这对我来说看起来有些混乱。但与此同时，通过只使用queryparam过滤器直接在产品资源上解决它来解决这个问题并不是很好，并且不会强制调用者提供StoreId和进程：
/api/products?store=1234&process=retail
/api/products/ABCD/prices?store=1234&process=retail
更重要的是，process或storeid与产品没有任何关系，因此直接在产品上查询它似乎很奇怪。但是对于价格来说，这是有意义的。
所以我的问题是：有没有一种解决这个问题的好方法，我不明白？并且：你会建议在它们是子资源时返回完整的产品吗？你在做这些事情时对处理（HTTP）缓存有何看法？
答案 0 :(得分：0)
这里提出的第一个问题是我是否应该回来 这里的产品或/ api / products /上各自资源的URI [...]骗局就是这个 会对/ api / stores / 1234 /零售/产品造成缓解问题 URI。
我肯定会返回完整的产品 - 想象一下，如果只想显示产品名称列表，客户必须要做的金额。理想情况下，此端点将被分页（查询字符串可以包含类似&pageSize=10&pageNumber=2的内容）。
此外还有各种缓存解决方案 - 例如，您可以将所有产品缓存在Redis等数据结构服务中。
为了使事情变得复杂，那些产品当然也有价格[...] 和细节子资源。
查看Richardson Maturity Model level 3，这将是链接发挥作用的地方，您可以在产品资源下使用此类内容：
<link rel = "/linkrels/products/ABCD/prices"
uri = "/products/ABCD/prices?store=1234&process=retail"/>
和产品详细信息资源的另一个类似链接。