在 WS API 中的性能和易用性之间进行选择
我们正在为我们的产品创建一个新的 API，该 API 将通过 Web 服务公开。 我们内部争论 API 是否应该尽可能易于使用（以进行更多调用为代价），或者使其尽可能高效（使其更难使用）。 例如，出现了两个问题：
- 我们应该在服务器上管理会话信息，还是应该将该信息传递回用户，并期望他在需要时将其发送回给我们？ （请忽略会话的安全隐患）
- 我们是否应该组合可能发生的调用，以节省其间往返所花费的时间，即使它们并不真正共享相同的逻辑功能？
基本上，桌面用户倾向于清晰、易于使用的 API，而互联网用户则希望使其尽可能高效。 这是我们提供的第一个公共 API，我们需要一个策略。
就我个人而言，我赞成使 API 尽可能可用。 系统上的其他组件可能会对性能产生更大的影响，并且难以使用的 API 更容易出错。 但我是一名桌面程序员……
那么，我们的策略应该是什么？ 创建此类 API 时的常见做法是什么？
We're in the process of creating a new API for our product, which will be exposed via web services. We have an internal debate whether the API should be as easy as possible to use (in the price of making more calls) or make it as efficient as possible (rendering it harder to use). For example, here are two issues that came up:
- Should we manage session info on the server, or should we pass that info back to the user, and expect him to send it back to us when needed? (Please ignore the security implications of a session)
- Should we combine calls that are likely to be consequent, in order to save the time spent on the round trip in between, even if they don't really share the same logical functionality?
Basically, the desktop people are in favor of a clear, easy to use API, while the internet people would like to make it as efficient as possible. This is the first public API we're providing, and we need a strategy.
Personally, I'm in favor of making the API as usable as possible. Other components on the system are probably going to have a much larger affect on the performance, and hard to use APIs are much more error prone. But I'm a desktop programmer…
So, what should be our strategy? What are the common practices when creating such an API?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
典型的使用场景有哪些？ API 的延迟会决定 UI 响应能力吗？ 性能权衡会有多大？ 在不了解您的情况的情况下很难提出任何建议。
但
我的猜测是，将会话信息传递给客户端会更好地扩展。 进程内会话管理不允许您在服务实例之间共享状态。 在数据库中管理会话将使您的服务更加复杂。 无论如何，这一切都取决于您的带宽/内存/计算能力。
我会从最细粒度的操作开始，仅在性能问题变得明显时才提供复合方法。
What are typical usage scenarios? Will the latency of your API determine the UI responsiveness? How big the performance trade-off will be? It's hard to suggest anything without knowing your circumstances.
But
My guess is that passing session info to the client will scale better. In-proc session management won't allow you to share the state between service instances. Managing sessions in DB will make your services more complex. Anyway this all depends on your bandwidth/memory/computational power capabilities.
I would start from the most granular operations and only provide composite methods when performance problem becomes obvious.
IMO，最好的方法是为必须使用您的 API 的人提供最简单的 API，但让这些人拥有深度定制的可能性，以使其高效，即使更难使用。
但对于用户来说简单性> 全部。
IMO, the best is to have the simplest API for people who will have to use your API, but letting these people have deep customizing possibilities, to make it efficient, even if harder to use.
But simplicity for users > all.
我建议您按照 RESTful 模型 创建 Web 服务，这意味着无状态。 效率比易用性更重要。 稍后您始终可以在 API 之上创建一个框架，以缓解实施难题。
I would recommend you create your web service following the RESTful model and that means stateless. Efficiency is more critical than ease of use. You can always create a framework on top of the API later that eases implementation headaches.
你正在争论一个循环论证。 这就是可用性（易用性）。
您可能会同时考虑这两个方面 - 因为它们都会影响用户性能。
这是（i）可定制功能的范围与（ii）操纵这些功能的效率的情况。 两者之间会有交集。
我想说的是提供一个简单的 API，将控制权交到用户手中 - 这是 CMS 的主要目的。 您最初可以组合更详细的方面，稍后将它们作为附加控制引入。
通过这种方式，您将管理用户的系统学习曲线，以便 (i) 最初不要用过多的选项轰炸他们，并且 (ii) 让他们首先快速采用您的系统。 然后通过提供更多 API 功能来扩展您的用户控制（从用户角度来看系统功能）。
另一个好的建议是预先询问用户并提供帮助。 当你去时。
You're debating a circular agrument. This is all usability (ease of use).
You're likely going to factor in a bit of both aspects - as they both influence user performance.
Its a case of (i) extent of customsiable features versus (ii) efficiency in manipulating those features. There will be an intersect between the two.
I'd say give a simple API that puts control into the users hands - this is the primary purpose of CMS. The more detailed aspects you could combine initially, introducing them as added control later on.
This way you will manage users learning curve of the system so as (i) not to bombard them with excessive options initially and (ii) allow them to adopt your system quickly at first. Then extend your users control (system functionality from a user perspective) later on by making more of the API features available.
Another good tip would be to ask you users upfront & as you go.
我的 2 美分：
首先从提供高性能的非常细粒度的低级 API 开始。
然后创建一个由上述低级 API“组成”的易于使用的高级 API。
这样客户就可以根据自己的需要定制他们的行为。 客户端可以从使用高级 API 开始，但如果某些用户操作期望获得高性能，他们可以根据具体情况使用更快但困难的低级 API。
服务设计中需要考虑的另一重要点。 尽量让他们保持无国籍。 无状态 Web 服务的优点是可以使用网络负载平衡轻松分发它们。
My 2 cents:
First start with a very granular low level API that gives high performance.
Then create a easy-to-use high level API that is "composed" of the above low level API.
This way clients can customize their behavior as they want. The clients can start with using the high-level API but if high performance is expected for certain user actions, they can use the faster-but-difficult low level API on a case-by-case basis.
One more important point to consider in service design. Try to keep them as stateless as possible. The advantage of stateless web services is that they can be easily distributed using Network Load Balancing.