这是一个通用设计问题，但在这种情况下责任应该落在哪里？调用者是否有责任检查记录是否已存在，然后调用更新？或者应该由API负责做出决定？
在第一种情况下，问题是调用者负担业务逻辑，但在第二种情况下，逻辑会污染API并创建混合行为，违反了关注点分离原则。
答案 0 :(得分：0)
实现CreateOrUpdate端点将破坏一些REST原则，但对于应用程序开发人员来说可能很方便。您正在考虑远程函数调用，而不是面向资源的API。
请考虑这一点：API URL标识资源。
如果URL指向集合（即/ customers /），那么Create操作（通常映射到POST方法）肯定是有意义的。如果您希望允许在一个资源上更新多个资源，则更新功能可能有意义。 POST应该将代码201和标识符返回给新创建的资源（即/ customers / 1）;或者如果由于资源已经存在而导致创建失败，则应返回代码409;如果不满足数据验证等其他约束，则为400。
如果URL指向现有资源（即/ customers / id / 1），那么Create操作没有意义，应该产生代码400.更新通常映射到PUT方法（或者某些PATCH，如果是资源更新）如果更新成功通常会返回200，否则返回4xx系列。
如果您选择创建一个/ CreateOrUpdate端点，它接受POST请求，您将不得不围绕它设计自己的协议，因为它的行为和返回值将根据情况而有所不同。
@Evert PUT可用于创建，但仅当您要求客户端使用标识符来表示端点URI时，
PUT /users/myusername
问题是：
我要说的主要是避免创建表示动作（函数）的REST API端点。而是使用HTTP方法对持久资源执行相应的操作。