在 Sinatra for Rails 应用程序中构建后端 API 是个好主意吗?还是使用Padrino更好?我想让我的后端提供 API 作为服务,因此,如果我必须为任何客户端开发相同的应用程序,我可以随时使用该后端 API(Web 服务)。最好的方法是什么?我的目标是将后端公开为 Web 服务,甚至 Rails 也将其用于 webapp。不同方法的缺点或优点是什么?
2 回答
虽然我不会在这里展示任何代码,但以下是我想建议的几件事。
在 Sinatra for Rails 应用程序中构建后端 API 是个好主意吗?还是使用Padrino更好?
如果您的应用程序要与 DB 和其他类似方面对话,我建议使用 Padrino。帕德里诺将为您节省时间。使用 Sinatra,您最终将围绕它配置堆栈。Padrino 在生成器和助手方面提供了很大的灵活性,允许您挑选堆栈并开发您的应用程序。
我想让我的后端提供 API 作为服务,因此,如果我必须为任何客户端开发相同的应用程序,我可以随时使用该后端 API(Web 服务)。
我不能谈论 SOAP,因为我还没有研究过它。如今,REST 更受欢迎。您可以考虑使用Grape之类的东西,而不是直接使用 Sinatra 或 Padrino 来绘制路线图。
引自 Grape Doc
Grape 是 Ruby 的类似 REST 的 API 微框架。它旨在通过提供简单的 DSL 来轻松开发 RESTful API 来在 Rack 上运行或补充现有的 Web 应用程序框架,例如 Rails 和 Sinatra。它内置了对常见约定的支持,包括多种格式、子域/前缀限制、内容协商、版本控制等等。
最好的方法是什么?
这是一个非常开放的问题。最好取决于很多因素。
我的目标是将后端公开为 Web 服务,甚至 Rails 也将其用于 webapp。不同方法的缺点或优点是什么?
当然,如果 API 将被除您的 Web 应用程序之外的其他应用程序使用,那么这具有显着的优势。例如移动应用程序。
我看到的缺点是网络延迟和网络健谈。
但是,如果有大量的卷,这应该会很好。如果您计划在多个实例上扩展应用程序,您可能需要在编写应用程序时考虑一些事情。例如会话管理。
将后端作为服务是一种很好的方法,因为它可以更好地解耦代码。我认为,是使用 Sinatra 还是 Padrino,更多地取决于后端应该处理多少管理任务。
如果后端是 API-only,那么 Sinatra 和一些 API gem(例如RABL)可能是最简单的。
但是,如果您希望后端使用它自己的管理任务界面(甚至对于不应该在前端可用的紧急工作),那么具有相同 gem 的 Padrino 可能是更好的方法,因为它处理更多复杂的网络应用程序。
编辑: RABL 与 Sinatra 纯 JSON 输出的示例:
让我们以 RABL README 中的简单示例为例。要获得如下输出:
[{ "post" :
{
"id" : 5, title: "...", subject: "...",
"user" : { full_name : "..." },
"read" : true
}
}]
你需要把它放在 Sinatra 中:
get '/' do
posts = # find some posts somewhere
user = # detect current user
json posts.map do |post|
{ post:
{
id: post.id,
title: post.title,
subject: post.subject,
user: post.user.full_name
read: post.read_by?(user)
}
}
end
end
但是 RABL 更具声明性,因此,您只需编写:
get '/' do
@posts = # find some posts
@user = # detect current user
end
# app/views/posts/index.rabl
collection @posts
attributes :id, :title, :subject
child(:user) { attributes :full_name }
node(:read) { |post| post.read_by?(@user) }
我倾向于认为纯 JSON 输出很快就会失控,但是使用 RABL,您可以使用部分和继承来分解 JSON,并使其更易于维护。