【发布时间】：2014-06-21 09:27:34
【问题描述】：
在开发 Web API 时，更喜欢什么，Web API 标准还是性能？例如，要更新（PUT）一组对象（将它们的一个属性更改为一个公共值），我可以接受一个对象列表并通过优化性能 Count(object) 次来更新它们。
【问题讨论】：
标签： .net rest asp.net-web-api
【发布时间】：2014-06-21 09:27:34
【问题描述】：
由于没有关于如何实现 RESTful API 的真正规则，这取决于您。
如果您可以通过支持批量 PUT 让每个人的生活更轻松一点，那就去做吧。
想想吧。假设您要更新 100 个资源，您是要进行 1 次调用，还是 100 次？ 100 次单独的调用可能会很昂贵，就像性能和所花费的时间一样。
这也可能取决于您的服务器是如何实现的。在我链接到此答案底部的第一个问题中，提到当您想要支持错误报告时，执行批量请求可能会导致问题。
无论您选择什么，只要确保 API 的用户确切地知道如何形成有效请求以及他可以期待什么响应。
【讨论】：
-
是的。我必须实现一个“错误报告”生成代码。但它值得性能提升。
-
@ime 是的，我同意这可能是值得的，特别是如果您使用的系统限制了您每天可以进行的 api 调用量
如果大多数客户端可以发出更少的请求来获取或修改更多数据，它们的性能会更好。将批量操作构建到您的 API 中以支持这种用例是个好主意。
如果您对性能如此感兴趣，那么值得考虑以下几点：
-
连接：保持活动状态：为多个 API 请求保持与 API 服务器的连接可以大大提高性能。如果配置正确，几乎每个 Web 服务器都应该支持保持连接。一些 HTTP 客户端库需要您做一些额外的工作来启用持久连接。持久连接会对您的 API 的感知性能产生重大影响。
-
Expect: 100-Continue：如果 API 客户端即将发送一个包含大型实体主体的请求，例如 POST、PUT 或 PATCH，他们可以发送“Expect: 100-continue” ”在他们的 HTTP 标头中，并在发送他们的实体正文之前等待“100 Continue”响应。这允许 API 服务器在浪费带宽返回错误响应（例如 401 或 403）之前验证请求的大部分有效性。支持这个功能不是很常见，但在某些场景下可以提高 API 响应能力并减少带宽。 (RFC2616 §8.2.3)。
-
HTTP 压缩：HTTP 压缩可用于响应正文（接受编码：gzip）和请求正文（内容编码：gzip），以提高 HTTP API 的网络性能。
最大化性能是令人钦佩的，但归根结底，如果您时间紧迫并且需要交付一些东西，那么您需要务实并继续做事。
【讨论】：