api - 是否有必要为移动应用程序构建单独的 API 端点以访问 Rails Web 应用程序？

Question

我有一个在 Ruby on Rails 4 中实现的 Web 应用程序，需要一个 Android native 应用程序，我对移动开发非常陌生。

在这种情况下，我对移动网络架构应该是什么样子感到有些困惑。我在网上做了一些研究，似乎有几种方法可以做到这一点，但我仍然有一些我无法找到答案的问题。在此先感谢所有指点。

1) 我真的需要一个单独的移动应用程序 API 吗？将我的 Rails 应用程序的现有 Controller 与 respond_to 一起使用有什么问题？ format.json ?

2) 我看过一些在线示例，这些示例建议在 Rails 应用程序中使用单独的 API 命名空间来处理移动请求，例如 class Api::ApiController < ActionController::Base对于新 Controller ，然后添加 namespace :api do在routes.rb。使用这种方法，是否意味着我需要在这个新的命名空间中为移动设备复制相当多的 Controller 功能？

3)关于认证，很多例子都建议使用token认证，Rails内置的 session 管理框架对手机app不够好？还是因为 session cookie 在移动应用程序中的工作方式完全不同？

珍惜你的时间。

Answer 1

这不是必需的，但正如您所说，它被认为是最佳实践。

1+2) 乍一看，使用带有 response_to/respond_with 逻辑的相同 Controller 是一个不错的主意。但是，根据我的经验，我可以说，总会有一天 API 代码开始与 HTML 客户端代码不同。移动客户端可能有不同的用户界面，很自然，它会期望以另一种方式使用您的数据，就像您的 Web 客户端一样。 Web 客户端专门用于一种用例，其中 API 应该更通用，允许多种消费方式。

将出现的第二个问题是，您不能依赖移动用户始终拥有最新的应用程序版本，而 Web 应用程序则可以。因此，对于 HTML 应用程序，您可以轻松地引入不兼容的更改，因为您在移动 API 破坏 API 至少令人担忧的地方提供了合适的客户端。也许，您会想要保持向后兼容性，这将使您的通用 Controller 变得丑陋无比。如果没有适当的 api/v1 命名空间，您甚至无法同时拥有两个不同的 API 版本。

您可以通过保持 Controller 非常精简并将逻辑移到模型中来避免逻辑重复(服务对象也是模型，而不仅仅是事件记录)。

3) 您的移动 HTTP 库很可能会有适当的自动 cookie 管理。基于 token 的身份验证再次成为最佳实践。如果它只是 cookie 中的 token vs session_id，则不会有太大的胜利。我只能认为它会自动抵御 CSRF 攻击，您可以完全为 API 禁用此保护，因为您的网站用户将不被允许使用 API，只需登录该站点即可(可能是额外的好处) .使用基于 session 的身份验证，您必须在第一个 API 请求上生成 CSRF token 并将其设置在 X-CSRF-Token 内。曲奇饼。

基于 token 的身份验证的一大优势是它可以扩展到更高的安全性，例如引入过期 token 、HMAC token 等，而 session 身份验证则不然。
见 Using Sessions vs Tokens for API authentication

我也鼓励您查看 json:api .它来自 ember.js 的创建者，他们在构建 API 时考虑过缩小要采取的决策。另一个有趣的事情是 active_model_serializers gem 。在 Rails: The Next Five Years by Yehuda Katz 中给出了它的介绍