1 个服务端点与 3 个用于在 CRUD 中创建/更新/删除的单独端点 |建筑学

Question

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

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

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

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

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

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

感谢回答

Answer 1

这实际上取决于您计划如何实施该服务。如果您要使用已建立的框架，例如 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 风格的端点和已建立的框架，以便从更广泛的人才那里招聘池，而不是在您定制设计的系统上进行招聘和培训。