实现 HATEOS REST API 以返回聚合 Order 对象的最佳方法是啥?
Posted
技术标签:
【中文标题】实现 HATEOS REST API 以返回聚合 Order 对象的最佳方法是啥?【英文标题】:What is the best approach to implement HATEOS REST API to return an aggregate Order object?实现 HATEOS REST API 以返回聚合 Order 对象的最佳方法是什么? 【发布时间】:2021-04-19 00:57:31 【问题描述】:我正在使用 .net 核心并有两个名为 Customer_Api
和 Order_Api
的微服务。我正在尝试坚持 RESTful 最佳实践并应用 HATEOS。我有一个看起来像这样的Order
模型类:
public class Order : BaseEntity
public string TransactionId get; set;
public decimal Total get; set;
public Guid CustomerId get; set;
public virtual Customer Customer get; set;
public Guid DeliveryAddressId get; set;
public virtual OrderDeliveryAddress DeliveryAddress get; set;
public ICollection<OrderLine> OrderLines get; set;
假设:
-
假设这是一个中等规模的电子商务系统,有大量请求进入我们的微服务
我们的订单类代表了正确且足够的结构
问题:
现在,我正在编写一个 GET
API 来返回单个 order
。如果我想坚持使用 HATEOS,这是否意味着 API 响应不应包含客户对象(例如客户姓名),而只需返回客户 ID 和 URL 链接,客户可以使用该 URL 链接从客户微服务?对于订单行和交货地址,或者基本上,对于可能进入我们的Order
对象的任何其他资源,我们应该返回相对的 GET URL 而不是对象本身。坚持HATEOS?
我会说订单对象的 HATEO 响应在 JSON
中应该如下所示:
"transactionId": "blabla",
"customerId": "blabla",
"customerUrl": "https://localhost:443/customer/blabla",
"orderLines": [ "id": "bla", "orderUrl": "https://localhost:442/order/bla" ],
....
这有意义吗?或者这是过度杀戮?或者可能效率不高?如果有人能证实我的想法或为我澄清这一点,我们将不胜感激。
【问题讨论】:
启发式:想想你将如何在网络上使用 html 进行操作。 【参考方案1】:我认为您可以有一种方法来创建 HEATOS 链接。该方法transactionId
customerId
orderLines
并在结果响应中构建并附加customerUrl
。
例如
//exaple reository
public order GetOrderRepository()
Random r = new Random();
return new order()
orderId = r.Next(0, 99999)
;
//exaple endpoint
[HttpGet]
public ActionResult<order> getOrder()
var order = GetOrderRepository();
return Ok(GetOrderWithHeatos(order));
//our HEATOS builder
public order GetOrderWithHeatos(order order)
order.orderUrl = new Uri($"AbsloutePath/order.orderId").ToString();
return order;
【讨论】:
以上是关于实现 HATEOS REST API 以返回聚合 Order 对象的最佳方法是啥?的主要内容,如果未能解决你的问题,请参考以下文章
PayPal REST API - 沙盒为 API 请求返回 401 但访问令牌成功
(二)Django REST实践:最简单的REST API实现