移动客户端不应该终止与 API 的连接吗？答案

【问题标题】：Shouldn't mobile clients terminate connections to API?移动客户端不应该终止与 API 的连接吗？
【发布时间】：2019-12-13 18:42:47
【问题描述】：

我正在开发一个使用 API 的 iOS 应用。 API 有一个文本搜索，我们已经实现了一个 debouncer，以确保我们不会在用户每次在搜索字段中写入字符时执行搜索。我们在每个字符后等待 0.2 秒，看看是否会出现另一个字符。如果用户写“Washingto”并用 0.205 秒输入最后一个“n”，我们首先发起对第一个单词的搜索，然后在 0.005 秒后立即取消。我们使用标准客户端 API 取消请求（例如 iOS 的 URLSessionTask.cancel）。

这已经完美运行了一年。但是今天，我们收到了来自（外部）API 的警告，说我们需要停止像这样取消我们自己的查询。他们的原因是他们的网关 Apigee 不能很好地处理它，并且他们收到了数英里的状态码为 499 的日志。

据我所知，它们暗示我们必须保留请求并接收响应，这意味着更多的数据使用（移动）、更多的处理器（解析）和更多的电池使用。

这个“问题”真的只有这样解决吗？我认为我们在这里的客户正在做最佳实践，但他们声称 Apigee 声称客户不应该像这样关闭连接。

另外，我不确定要使用哪些标签或在哪里问这个..

【问题讨论】：

您正在使用一个很好的做法。谁告诉你这很糟糕？
我们正在使用的 API 的操作员（所有者）。他们从字面上（翻译）“这主要是因为我们的网关产品 - Apigee - 不能很好地处理这个问题。他们还声称这不是一个好的实践客户端实现。这可以讨论，我看到你取消不可用请求的理由，但 apigee 在这个主题上处于领先地位，所以这样做不能成为“标准做法”。我正在努力从 Apigee/Google 找到任何文档这说明了有关取消请求的任何内容。
您可能应该找到一些 Apigee 论坛或在他们的网站上询问他们的建议。最后，您可以获得请求的 ID，并且不解析已取消的请求
不要为取消现有请求而烦恼；让它完成并在第二组结果结果通过时替换结果。

标签： ios rest server client apigee

【解决方案1】：

只有一些（部分）观察：

1) 在本地执行查询会消耗更少的电量，因为您不必抬起天线、打开 wifi/4G 或类似的电源...

2) 您在几秒钟内向服务器发送数百万个 https 请求（我希望您有 100K 用户.. :) 输入 4 个或更多字符...）因此服务器也面临压力。

2) 等待超过几毫秒的用户体验很差。

我可以理解您的数据库在远程，但使用本地（简化）Sqlite Db 可以获得更好的体验（我们在后台下载了压缩包）

【讨论】：

它是动态数据，所以本地是不可能的。而且我不确定你是否理解这个问题。我们有 80 万用户，但服务器根本没有压力。他们的问题是我们正在取消请求，而不是请求太多。他们希望我们停止取消请求，坐下来等待响应并解析并丢弃它，而不是主动告诉服务器我们不想要响应。
我明白。一个真正的问题。