如何正确构建 "PUT method" 并做到 "intern request"?

How to build properly "PUT method" and do "intern request"?

我是 Spring 和 Java 的新手(我可能不会使用正确的词汇,尤其是英语),我正在尝试建立一个微型数据库。但是我对 PUT 方法的语法有疑问。 (目前一切正常)

所以我有一个名为 GameEntity 的 public class,它包含一个 id,一个 name 和名为 PlayerEntity 的对象列表 (我从 Whosebug post 中删除了导入只是为了看得更清楚)

public class GameEntity {
    @Id
    @GeneratedValue
    private Integer id;
    private String name;
    @OneToMany
    private List<PlayerEntity> players;

    public GameEntity() { }

    public Integer getId() { return id; }
    public void setId(Integer id) { this.id = id; }

    public String getName() { return name; }
    public void setName(String name) { this.name = name; }

    public List<PlayerEntity> getPlayers() { return players; }
    public void setPlayers(List<PlayerEntity> players) { this.players = players; }
}

PlayerEntity 对象的构建方式与 GameEntity 相同,只是有一个 id和一个 name.

这是 GETPOST 的映射(对于 玩家实体):

@RestController
public class GameController {
    private final GameRepository gameRepository;

    public GameController(GameRepository gameRepository) {
        this.gameRepository = gameRepository;
    }

    @GetMapping("/games")
    public List<GameEntity> getAllGames() {
        return this.gameRepository.findAll();
    }

    @PostMapping("/games")
    public GameEntity createGame(@RequestBody GameEntity gameEntity) {
        return this.gameRepository.save(gameEntity);
    }
}

现在,我可以“POST”一个 GameEntity 和一个 PlayerEntity,但我想将 PlayerEntity 创建到 GameEntity[=55] 中的 PlayerEntity 对象列表=].

所以我想我必须“PUTGameEntity 创建。但是我怎么才能 "reach" PlayerEntity 呢?我可以做一些类似内部请求的事情吗?语法是什么? 做两个请求来创建两个对象并将一个对象放在另一个对象中是最好的方法吗? 直到现在我还错过了什么吗?

我有点迷茫,任何建议都会有很大帮助!

提前致谢。

如果两个对象都可以独立生活,那么它们都应该有一个 POST。我假设在创建游戏时您的玩家已经存在?在这种情况下,当您 POST 游戏时,您可以立即将玩家包含在其集合中。

如果您需要更新玩家列表,有多种方法:

  1. PUT /game/{id} 包括所有玩家。请注意,PUT 理想情况下应覆盖整个资源,因此应包括游戏的所有字段。
  2. PUT /game/{id}/players 用新玩家替换以前的玩家列表。同样 - 包括整个列表,但现在您不必发送游戏的所有字段。
  3. POST /game/{id}/player - 将新玩家添加到游戏中。这个是 POST 因为这样的端点将不再是幂等的。如果你这样做,你还必须创建 DELETE /game/{id}/players.
  4. 对于更复杂的操作,您可能需要考虑 PATCH - 它可能是非幂等的,可以部分更新资源。

前 3 个是 RESTful,最后一个不是 - 动词可能开始爬入 URI。

一般而言,幂等架构更安全、更简单,因此您应该首先考虑第 2 个。如果它很复杂 - #3 也可以。如果您认为它不可行(例如由于性能下降或其他因素),那么您可以考虑第 4 个选项。