【问题标题】:Best practice for POST requestPOST 请求的最佳实践
【发布时间】:2021-05-07 19:06:54
【问题描述】:

我正在使用一些 API 制作一个 REST ASP.NET 核心,稍后我将在 Android 应用程序中使用这些 API。

我对一些数据库操作有些疑惑。

假设我在我的数据库中有一个表门票,其中包含 id、title 和 author 列(这是一个引用 User 表(id​​ - name)的外键) 现在,当 Sndroid 应用程序请求票证列表时,我进行了选择并返回了作者的 id、标题和 name,因此我制作了一个这样的票证类:

class Ticket{
private int id{get; set;}
private string Title {get; set;}
private string author {get; set}
}

现在假设应用发送 POST 请求以添加新票证。最佳做法是什么? 发送作者的titlename(客户端在本地数据库中有作者表的副本)或title作者的ID。 所以在第一种情况下,我有一个像上面那样的新票的类(没有 id),我必须进行选择以获取作者的 id 并在数据库中插入。在第二种情况下,我有一个这样的课程:

class Ticket{
private string Title {get; set;}
private int author {get; set}
}

并且无需进行选择即可获取作者的 id。 哪一个是最好的?有两个不同的类或只有一个在数据库上有多个操作(获取作者的 id)。 现在我简化了这个例子,但是想象一下票有更多的外键列,什么是最好的?

【问题讨论】:

    标签: c# sql asp.net kotlin backend


    【解决方案1】:

    您应该了解您的域对象是什么。从描述中我会说你至少有两个:作者和票。

    在这种情况下,作者创建了一张票,例如在 POST 作者/{authorId}/tickets 上。在这种情况下,您返回票证,即没有作者 ID,因为客户端已经知道作者(TicketDTO:id,标题。请参阅下面的 DTO)。

    此外,您对任何特定 EP 的回馈取决于您的业务需求,即取决于您的 API 客户的需求。您有很多客户,其中一些是 3d 派对?使您的 API 尽可能通用。您有一个您自己写的客户,您确定其他客户不会来吗?如果需要,请返回更多信息,尤其是如果您可以节省一些调用并因此提高性能。

    最后但并非最不重要的一点是,您从数据库获取的对象不是您通过 REST API (DTO) 发送的对象。 DTO 可能包含来自多个 DB 对象的信息。您可以根据后端需求制作数据库,并根据客户需求制作 REST API。而不是您将 DB 对象映射到 DTO,例如使用 AutoMapper 或其他解决方案。

    【讨论】:

    • 好的,但是例如,当客户端发送 GET 请求以获取票证列表时,我必须返回每张票证的 ID、标题和作者。数据库已经存在,我必须用它来做后端。我的问题是。什么最适合 POST 请求?直接发送作者的 id 或发送他的姓名,然后后端进行选择以获取他的 id 并在数据库中进行插入?
    • 我会说你在帖子中发送作者的 id,而不是作为帖子有效负载,而是作为 url 的一部分:POST authors/{authorId}/tickets。如果需要,服务器将查询作者并将票证插入数据库。得到它取决于。客户是否查询所有作者,然后查询他们的票?比作者是你的聚合根,你有 GET authors 和 GET authors/{authorId}/tickets。您的客户查询门票清单?比你有 GET 票和 GET 票/{ticketId}/author 或者只是将作者包含在票 DTO 中:{id, title, author: {id, name...}}。
    • 这真的取决于您的应用程序的需求。 REST 给出了如何做事的建议,而不是硬性规则。首先定义你的资源,考虑它们的关系。哪个是主要资源(聚合根)?直接获取它们,例如 GET myresources。只有当您已经查询了聚合根时,哪些资源才有意义?通过主资源获取它们,例如 GET myresources/id/mysubresources。客户可以进行多次查询吗?制作通用的细粒度 API。客户资源受限?构建更大的 DTO 并包含更多信息。
    • 是的,客户端发出 GET 请求以获取所有票证。我不明白哪种方法更好:当客户发送 POST 以在数据库中插入新票时,他发送标题和他的 ID 或标题和他的名字(服务器将搜索他的 ID)
    猜你喜欢
    • 1970-01-01
    • 2020-11-20
    • 2021-01-02
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-02-22
    • 1970-01-01
    • 2017-09-12
    相关资源
    最近更新 更多