存在许多指南/gem 可帮助 Rails 开发人员通过 HTML 创建复杂的 Web 表单向导流程(例如 wicked)。然而，他们通常通过将 HTML View 的呈现与 Rails 应用程序本身紧密耦合来实现这一点——这种方法对于 Rails API 应用程序是行不通的，因为后端只能发送和接收 JSON，并且无法驱动 View 客户。
这为使用我的 API 的 iOS 和 Android API 客户端带来了两难境地，因为它们的向导分支逻辑中有很多都依赖于后端数据库数据。
问题:在为多个客户端构建复杂的向导流程时，Rails API 的最佳实践是什么？
例如对于 Rails API-only 应用程序，表单对象仍然是个好主意吗？状态机是简单的关键启发式方法吗？还是网络组件？或者我的 Rails API 应该让开——专注于提供基本的 REST 端点——让我的 iOS 和 Android 客户端自行决定如何通过复杂的向导验证和导航用户？!
非常感谢帮助。
最佳答案
在大多数情况下，您希望您的 Rails 服务器(或任何服务器，事实上)仅充当 REST API 服务，并让客户端代码(单页应用程序或 iOS/Android app) 负责导航流程和布局。
在极少数情况下，您希望服务器调用应该进行导航的位置，我建议您在 JSON 响应中传递一个参数 to，并带有某种指示， fragment 或路由，告诉您的客户端下一步将用户发送到哪里。这不是一个很好的解决方案，因为客户端代码通常应该与服务器端代码分离，并且使用这种方法你必须在客户端和服务器端管理你的路由，但它会做你想做的，也许。
关于android - 当客户端是 native 移动应用程序时，处理向导流程的 Rails API 最佳实践？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48899002/