在使用SOAP RPC接口之后，我一直在努力解决如何以适合RESTful设计模式的方式处理事物。
例如。如果我们有一个有3页的新客户的注册向导。
名称/ DOB的第一页 地址的第二页 其他东西的第三页 客户完成注册的最终摘要页面
新客户的帖子将从最终摘要页面执行，这很明显，但您如何建议对每个页面上输入的数据进行验证。
第1页上的数据不是客户资源，它是部分客户资源，需要针对某些服务器端业务规则进行验证（例如DOB和唯一用户名 - 或者其他不能在JavaScript中实现的内容）客户验证）。
验证失败的结果可能是提供备用用户名，因此不仅仅是200/400状态代码响应。
RPC设计是对ValidatePage1方法的调用。
但这是在考虑行动＆＃39;验证＆＃39;关于数据项，我试图从资源和行动结果进行思考。
对于API进行REST和RPC类型调用是不好的设计，还是有时候这种方法在处理验证＆＃39;操作时有效？它实际上是动作，而不是资源帖子/获取等.ValidateDOB，ValidateAge，ValidateAddress等。
答案 0 :(得分：1)
例如。如果我们有一个有3页的新客户的注册向导。
名称/ DOB的第一页地址的第二页其他内容的第三页客户完成注册的最终摘要页面
如果您要将此作为HTML执行，协议可能看起来像这样 - 您将使用书签来查找资源，这将为您提供空白表单的表示。
您将填写表格，提交;浏览器将查看表单上的控件以发现表单的目标资源，构造表单数据的表示形式，并将该表示形式分派给服务器。服务器将验证您的输入，并返回（a）应用程序状态的表示以及所示的错误，或（b）应用程序状态的表示，其中有效字段已锁定，并且新表单用于收集下一页数据。此新表示中的超链接可能与前一个表单位于同一位置，或者可能位于其他位置。
在某些时候，您提供表单的表示，数据完整且有效，并且您将进入一些新的应用程序状态，您无需再填写这些表单。
如果你这样做，你就有了REST。
状态代码怎么样？好吧，每次提交表单时，资源都会以新应用程序状态的表示进行响应，因此即使在验证失败并且我们将工作发送回的情况下，以200（OK）响应也是完全合适的。用户进行重建。
请注意，此设计完全不依赖于：