我有一个支持POST到'/ foo'的Foo REST控制器来创建一个新的foo对象。
为简单起见，我们假设User对象只有一个昵称字段。
服务器当前进行各种验证，以确保可以保存foo。 （例如，登录用户具有访问权限或用户名不包含无效字符）如果无法创建新的foo，则返回400中的错误代码，并附带错误消息列表。
但是，我希望能够警告api的用户，昵称可能无法按照预期的方式运行。 （例如，如果与我们的一个遗留功能一起使用，那么他们已经拥有了具有该昵称的foo或该昵称将无效。）
我绝对不想完全阻止他们用这样的昵称创建一个foo，但他们应该知道潜在的问题，如果他们愿意，还有机会回去。
我认为有三种方法可以解决这个问题：
添加一个'/ foo / validate'端点，允许他们希望进行foo的POST（或可能的PUT）。此端点将以允许它们区分的方式返回任何致命错误和非错误。如果没有致命错误，他们会知道对'/ foo'的POST会成功创建一个新对象，因为'/ foo'不会对非致命错误执行验证。
向foo对象添加一个参数，如'force'。如果用户在没有将'force'设置为true的情况下对'/ foo'执行POST，则服务器将中止为致命和非致命错误保存新实例。如果用户注意到只返回了非致命错误，他们可以将'force'设置为true并再次尝试。这次，非致命错误将被忽略，并且将创建新的foo。
如果用户使用仅具有非致命错误的对象执行POST，则服务器会创建新的foo，并且在响应正文中会出现这些错误的列表（以及非201状态代码） ？）。然后，用户可以决定是否要a）保持对象原样b）更新新foo以避免警告，或c）删除foo。
我意识到其中任何一个都可行，但我想知道哪种方法最符合Web标准。现在我输入了它们，我认为3可能是最接近的，虽然我不确定为创建的对象返回什么状态代码（201）但是并不完全'成功'。
思想？
答案 0 :(得分：0)
如果您确实希望支持具有非致命错误的资源，请使用选项3.状态代码应为201，因为资源已创建。这与它可能存在的任何问题无关。包括响应中的问题的详细信息以及客户端解决问题的超媒体控件。
但是，即使你知道他们会受到“潜在问题”的影响，你真的想让创作成功吗？听起来像一个受伤的世界。我个人会将POST保持为/foo，如果验证失败，请回复409 Conflict状态代码及其失败的原因。
答案 1 :(得分：0)
您可能需要考虑使用prefer header“handling = strict”或“handling = lenient”处理选项，以允许客户端选择他们想要继续的方式。
如果用户选择handling = lenient并且您检测到非致命错误，则返回201但还返回描述检测到的错误的http-problem正文。