0

我有这个关于构建 CRUD 服务的问题，我应该能够创建、更新、删除和从数据库中获取记录。

为了便于理解。我将使用我应该向其编写服务以执行 CRUD 的公司的示例。我应该添加一个员工，更新一个员工，删除一个员工，获取为公司工作的员工列表。

下面的 Object 将用作Create/Update/Delete的请求负载，EmployeeDomainObject 的 List 将用作Get 请求的响应

EmployeeDomainObject { "firstName": "string", "lastName": "string", "id": "string", "status": "ACTIVE" or "DELETE" or null }

  • 我应该选择 2 项服务吗？
    • Get的1 个端点根据公司 ID 获取列表
    • 创建/更新/删除的 1 个端点，它将接受EmployeeDomainObject作为请求正文并根据状态相应地更新数据库。
      • 如果请求的状态为：null --> 新记录 ID 将为空，保存时将生成一个动态 ID
      • 如果请求的状态为：“ACTIVE” --> 根据 ID 更新记录
      • 如果请求有状态："DELETE" --> 根据ID删除记录
  • 我应该选择 4 项服务吗？
    • Get的1 个端点根据公司 ID 获取列表
    • Create的1 个端点基于 EmployeeDomainObject 创建员工
    • 1 个更新端点，用于根据 EmployeeDomainObject 中的 id更新员工
    • Delete的1 个端点，用于根据 EmployeeDomainObject 中的 id 删除员工

服务的范围和要求： 1. 健壮性 2. 可维护性 3. 哪个更受服务驱动？4. 可扩展/可扩展

赞赏的答案

4

1 回答 1

0

这实际上取决于您计划如何实施该服务。如果您要使用已建立的框架，例如 Spring，那么您很可能会使用 4 端点方法并且没有status字段，因为 HTTP 动词 (GET/POST/PUT/DELETE) 会暗示状态。

您拥有的是真正的 RPC（远程过程调用）。该status字段是要调用的“方法”。纯 REST 将使用 HTTP 动词，而 RPC 将使用这种类型的方法调用。因此，如果您打算在不使用框架的情况下从头开始构建服务，那么您可以使用一个端点。status当您可以添加另一个字段时，我看不到只有 2 个端点的意义：

EmployeeDomainObject 
{
   "firstName": "string",
   "lastName": "string",
   "id": "string",
   "status": "ACTIVE" or "DELETE" or "RETRIEVE" or null 
}

并使用 POST。这不是 REST，但你不是在问它是否是好的 REST。

使用上述内容并没有什么“错误”，特别是如果您要从头开始构建服务（可能是资源受限等）。

端点只是客户端与服务交互的方式。这些交互是通过 4 个 REST 样式的端点还是 1 个 RPC 样式的 POST 到达的，都无关紧要。客户只是做它需要做的事情。

后果是针对服务器的。一个成熟的 REST 框架（例如 Spring）将为您提供一个良好的开端，但会将您绑定到 4 个端点。如果您可以随意设计服务器端，那么 RPC 风格的方法就没有问题。您仍然可以记录/审核/处理服务的权限，但您可能需要自己编写代码。

如果您打算构建大型项目并雇用大量程序员，那么您可能希望顺其自然并使用 4 个 REST 风格的端点和已建立的框架，以便从更广泛的人才库中招聘，而不是而不是在您定制设计的系统上进行招聘和培训。

于 2018-05-01T11:05:52.517 回答