通过Web Api在POST中返回对象是不好的做法？

Question

我正在使用Web Api,并且客户端每n秒发送一次心跳通知.有一个心跳对象是在POST而不是PUT中发送的,因为我看到它们正在创建一个新的心跳而不是更新现有的心跳.

此外,客户端要求他们检索所有其他当前在线客户端以及单个客户端具有的未读消息数.在我看来,我有两个选择:

1. 执行POST后跟GET,从纯粹的REST角度来看,这似乎更清晰.我正在进行创建和检索,我认为SOLID原则更愿意相应地拆分它们.但是,这种方法意味着两次往返.
2. 让POST返回一个对象,该对象包含与GET原本相同的信息.这将所有内容整合到一个请求中,但我担心这种方法会被认为是不明智的.这不是一个纯粹的POST.

选项#2 stubped out看起来像这样:

public HeartbeatEcho Post(Heartbeat heartbeat)
    {
    }

HeartbeatEcho是一个类,其中包含其他在线客户端的属性和未读消息的数量.

Web Api当然支持选项#2,但仅仅因为我可以做某事并不意味着我应该这样做.选项#2是憎恶,过早优化还是实用主义？

Answer 1

选项2根本不是可憎的.POST请求会创建一个新资源,但资源本身返回给调用者是很常见的.例如,如果您的资源是数据库中的项目(例如,Person),则POST请求将发送INSERT操作所需的成员(例如,名称,年龄,地址),并且响应将包含Person对象,该对象在除了作为输入传递的参数之外,它还具有可用于唯一标识对象的标识符(DB主键).

请注意,它对POST请求也完全有效,只返回新创建的资源的id,但这是您的选择,具体取决于客户端的要求.

public HttpResponseMessage Post(Person p)
{
    var id = InsertPersonInDBAndReturnId(p);
    p.Id = id;
    var result = this.Request.CreateResponse(HttpStatusCode.Created, p);
    result.Headers.Location = new Uri("the location for the newly created resource");
    return result;
}