我们正在为我们的产品创建一个新的API，它将通过Web服务公开。我们有一个内部的争论，即API是否应尽可能容易使用（以拨打更多电话的价格）或使其尽可能高效（使其更难使用）。例如，以下是两个问题：
基本上，桌面用户赞成使用简单易用的API，而互联网用户希望尽可能提高效率。这是我们提供的第一个公共API，我们需要一个策略。
就个人而言，我赞成尽可能使API可用。系统上的其他组件可能会对性能产生更大的影响，而且难以使用的API更容易出错。但我是桌面程序员......
那么，我们的策略应该是什么？创建这样的API有哪些常见做法？
答案 0 :(得分：1)
典型的使用场景是什么？ API的延迟是否会决定用户界面的响应能力？性能权衡将有多大？在不了解情况的情况下，很难提出任何建议。
但是
我的猜测是将会话信息传递给客户端会更好地扩展。进程内会话管理不允许您在服务实例之间共享状态。在DB中管理会话将使您的服务更加复杂。无论如何，这一切都取决于你的带宽/内存/计算能力。
我会从最细粒度的操作开始，只在性能问题变得明显时提供复合方法。
答案 1 :(得分：0)
IMO，最好的方法是为那些必须使用您的API的人提供最简单的API，但让这些人拥有深度定制的可能性，使其高效，即使使用起来更难。
但是用户简单＆gt;所有
答案 2 :(得分：0)
我建议您按照RESTful model创建自己的网络服务，这意味着无状态。效率比易用性更重要。您可以随时在API之上创建一个框架，以减轻实施难题。
答案 3 :(得分：0)
你正在辩论一个圆形的agrument。这是所有可用性（易用性）。
您可能会考虑两个方面 - 因为它们都会影响用户的表现。
它是（i）可关联特征的程度与（ii）操纵这些特征的效率的情况。两者之间会有交叉。
我想说一个简单的API将控制权交给用户手中 - 这是CMS的主要目的。您最初可以组合的更详细的方面，稍后将它们作为附加控件引入。
通过这种方式，您可以管理用户学习系统的曲线，以便（i）最初不要用过多的选项轰炸他们，以及（ii）允许他们首先快速采用您的系统。然后，通过提供更多可用的API功能，扩展用户控制（从用户角度看系统功能）。
另一个好的建议是提前向用户询问＆amp;你走了。
答案 4 :(得分：0)
我的2美分：
首先从一个非常精细的低级API开始，提供高性能。 然后创建一个易于使用的高级API，该API由上述低级API“组成”。
这样客户可以根据需要自定义行为。客户端可以从使用高级API开始，但如果某些用户操作需要高性能，他们可以根据具体情况使用速度较快但难度较低的API。
服务设计中需要考虑的另一个重点。尽量让他们尽可能无国籍。无状态Web服务的优点是可以使用网络负载平衡轻松分发它们。