RESTful API——处理依赖于其他更新的更新

RESTful API - handling updates that depend on other updates

本文关键字：更新 其他 处理 API RESTful 依赖于      更新时间：2023-09-26

我正在尝试设计一个RESTful API来为前端JS应用程序提供数据，并且在未来，一旦我开始编写它，它将成为一个本地移动应用程序。

我对前端开发相当陌生，所以API设计对我来说也相当陌生。我正在编写一个乒乓球联赛应用程序来开始我的学习，其中一个端点似乎与我读过的推荐API结构的任何示例都不太匹配。

我有两个实体，联赛和球员。一个联赛有一组球员，当一个结果被输入时，如果在比赛开始前胜利者低于失败者，那么球员就会在联赛中交换"位置"。

标准REST API可能有如下端点来更新联盟中特定球员的详细信息:

(POST/补丁)-/api/v1/联盟/{league-id}/球员/{player-id}

。/api/v1/联盟/1/球员/12

这很好，但在我的情况下，当结果被输入到web应用程序时，2个不同的玩家需要通过API更新他们的"位置"值。理想情况下，我会将此设置为数据库中的唯一字段，因此在任何给定时间内联盟中的每个位置只能有一名球员。然而，如果是这种情况，使用上述API端点，我的前端应用将需要根据输入的结果计算玩家的新位置，更新玩家1，然后如果成功更新玩家2(失败时回滚)。按照这个结构，位置字段不能是唯一的，因为在玩家1更新之后，他们都有相同的位置值，直到玩家2更新。

我能想到的唯一其他解决方案是有一些其他适当命名的端点，它接受一个"结果"对象，在服务器端计算玩家新位置的逻辑，相应地更新，并返回一些数据供UI重新绑定和更新。

所以我的问题是:你会选择上面列出的两种方法中的哪一种，为什么?

如果选择后者，您将从API调用返回哪些数据以供UI绑定?完整的球员数据?还是只更新了两个玩家?

谢谢

我想我看到了两个问题

  1. 你没有定义足够的资源
  2. 你混淆了http和你的域模型

试试这样

PUT /api/v1/matches/{match-id}
{ winner : { id }, loser : { id }, ... }

向API发送一条描述游戏结果的消息(POST是可以接受的，Put对于幂等性更好)。

作为此消息到达的副作用，将结果合并到您的域模型中。你的领域模型应该包含描述玩家在游戏结束时排名如何变化的规则。

当有人想看球员的排名时…

 GET /api/v1/leagues/{league-id}/standings

您将它们发送到一个资源，该资源返回模型中当前排名的表示形式。

uri的拼写并不特别重要;我更喜欢"排名"，因为我相信这在你的领域是真实存在的。但是，如果您希望反映资源的数据结构而不需要额外的上下文，则可以使用像

这样的拼写。
GET /api/v1/leagues/{league-id}/players?orderBy=position

客户端发送给您的请求正文中的数据表示不是您的领域模型中实体的序列化，它是针对您的领域模型的消息的序列化。

选择在哪里计算联赛中的位置是非常主观的-我建议在服务器上做，因为它涉及到再次搜索数据库(其他球员的分数)。

因为你有多个球员，你可以一次更新2个球员，它会更好地发送球员的分数在请求体与他们的位置，并返回计算完整的联赛信息在响应每个请求，因为这将简化你的客户端代码，并确保你得到最新的数据。

这个建议是基于你在一个联赛中没有很多球员的假设(可能是> 100)。在这种情况下，我建议方法1更好。

所以你的API URL可以是.

(POST)/api/v1/联盟/{league-id}

和你的请求正文，可以是

"玩家":[{"player-id":"101","newScore":"10"},{"player-id":"103","newScore":"20"})

你的回答可以是结果联赛的完整球员名单。

"玩家":[{"player-id":"101","位置":" 1 "},{"player-id":"102","位置":"2"},{"player-id":"103","位置":"3"}{"player-id":"104","位置":"4"}{"player-id":"105","位置":"5"})

相关文章：