在Rails 4中，如何组织外部API调用 - 使用模块还是类？

Question

8

我正在创建一个Rails应用程序，将使用SalesForce、FolderGrid（类似于Dropbox）等多个外部API来同步到我的数据库中。我以前从未与外部API调用过合作，因此创建了一些基本的Ruby脚本和散乱的方法来测试对这些资源的调用。现在我想在完整的Rails应用程序中实现它们。

到目前为止，我开始在我的/lib文件夹中创建一个目录来保存api调用模块/类。

/lib/apis/foldergrid.rb

现在我不确定组织代码的最佳方法是什么。在我的独立Ruby脚本中，我有用于“认证、创建文件夹、审计文件、下载文件”等的方法。

模块中应该包含什么？我需要模块吗？类中应该包含什么？如何确保我可以在需要时在我的模型和控制器中使用这些方法？有关外部API的最佳实践是什么？

非常感谢您提供任何资源、链接和/或更深入的理解。

- shroy

2个回答

1

模块应该包含什么内容？

一个模块应该包含被不同类共享的代码，或者可以添加到单个类中。

我是否需要一个模块？

不需要，你可以通过继承实现相同的功能。如果没有要共享的代码，那么你可能不需要一个模块。

如何确保我可以在需要的模型和控制器中使用这些方法？

你可以在控制器内使用类来访问它们：

SalesForceAPI.get_data

"模块还是类？"这是Ruby中一个古老的问题，也是其他支持两者的语言。

我会将每个API的功能封装在一个类中。例如，您可以有一个类。然后，如果您需要在身份验证、创建文件夹、审核文件或下载文件之间共享功能，则可以创建一个类。

需要访问类的每个类都将从它继承：

SalesForceAPI < API

您可以通过创建一个API模块，并将其混合到其他类中，实现相同的功能。在这种情况下，这主要是一种偏好问题，因为任何一种解决方案都是好的。

顺便说一句，我不知道对于身份验证、创建文件夹、审核文件或下载文件是否有很多共享功能，因为每个API可能工作方式很不同。但是，如果它们是REST API，则可以创建一些REST辅助方法并将它们放在API类中。

关于这个主题的一个很好、易于理解和完整的资源是Practical Object Oriented Design Ruby。

- B Seven

谢谢B Seven。这里有很多有用的信息！ - shroy

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- creativereason · Accepted Answer

我有一个应用程序也可以这样做（从多个API中提取数据），所以我可以告诉你我会做什么（或者在某些情况下，如果我重新开始，我现在会怎么做）。

数据存储

首先，如果您已经将从这些API中提取的数据持久化到Rails应用程序中，则将具有表示数据本身的模型。因此，在控制器中引用它们，除非您的控制器负责调用API。

其次，请确保利用现有的API Gems，以便您不必重新创建身份验证、解析JSON到应用程序和从应用程序解析JSON等功能。例如：有一个rest-force gem适用于Salesforce。

第三，我会将在API响应和您的模型之间映射数据的类制作成“普通的 Ruby 对象”，并将它们存储在 lib/apis 文件夹中（在这些情况下无需存储在模块中，但是这是我的看法）。它们最终可能非常实用，在映射数据的情况下，这是可以接受的。

在这些情况下，我会将它们放在一个或多个类中，在lib文件夹下的自己的文件夹中，以便在需要时可以将它们解析成Gem（或者如果你想花时间开始制作它们的Gem，我相信其他人也会受益）。我刚刚开始使用Infoconnect's API，这个API没有Gem（或任何语言的代码示例）。但我还没有走得很远。

如果需要，在V和C之间的代码中创建服务对象

如果您最终需要与API信息交互或调用这些请求的任何内容与用户进行交互，我建议将它们放在服务对象中，以便您的代码不会在视图或控制器中变得臃肿。