我有一个需要维护的Rails平台。它基于其构建了许多不同的Web应用程序。但是，现在客户正在请求一个API，以便他们可以将用户保留在其站点上，但可以利用我们拥有的一些自动化任务。
该平台用于构建保险应用程序，并允许其在线购买，以及提供下载与您的保单相关的文档的方式。
所以我在构建API时的问题是：
当我必须做很多事情，比如validate，创建user，user profile和policy，几乎在同一时间。我应该进行4个单独的API调用，并让客户端在其端进行4个调用。还是我应该打一个电话，该电话除了很多参数之外，可以验证客户端并同时创建所有这三个对象，从而简化客户端的操作？
在这种情况下，客户端可以同时获取所有必需的信息，因此它不像在其应用程序中有自然的流程那样暂停，它们可以对我的平台进行API调用。
在客户端上使用过许多API之前，我的直觉是尽可能简化客户端，让他们只进行一次调用。但是，这会导致functionsAPI 变得相当庞大，我也不喜欢这两者。
您如何建议我解决这个问题？
需要注意的是，我对客户端能否实现复杂的API并不十分有信心。
Answers:
两者都怎么样？有一个“ 低级 ”（可以这么说）的API公开系统的功能，并有另一个“层”公开客户可能想要的服务。该层将使用必需的低级API，但是如果客户端需要它们，这些API仍然会公开。
更新：还包括其他人提出的一些观点和意见。
考虑客户端是否需要调用较小的API方法之一，例如，在不同时调用createUser的情况下调用createUserProfile是否可行？如果没有，则不要公开该方法。谢谢NoobsArePeople2
一个简单但很好的观点。在API中公开某些内容的要点-您永远都不能公开它。暴露功能所必需的最低限度，然后扩展而不是暴露所有事物……好吧，那么它的裸露和进行更改可能会令人尴尬和尴尬。谢谢MichaelT
我认为您看错了方式。不用担心大| 小电话或大量| 几个电话。
考虑业务对象和可以执行的操作。为| 反对那些对象。
你有：
因此，您应该围绕这些对象创建API调用。
这个想法是基于业务对象及其动作创建原子或近原子操作。这将简化设计和编码-可以执行业务对象应该执行的，与思维模型或程序员期望相符的调用。当程序员或架构师与业务分析师讨论需求时，他们都可以使用相同的术语和一般的操作流程。
较大的多合一类型调用的问题是有副作用的风险。如果Policy.Create也产生了一个User并触发了其他操作，那么这将破坏程序员的期望。同样，许多小调用迫使程序员记住先调用A，然后再调用B，然后再调用C，以便执行“单个”业务操作。
电话的命名方式将取决于Rails和支持的Web服务将支持的内容。
为了更具规范性，这将创建一些带有许多参数的调用，并且在后端可能有多个被客户端遮挡的调用。您还将获得一些相当快速/简单的调用，其中API仅不过是基础例程的包装器。
createUserProfile而不提供createUser？如果没有，请不要暴露它。