在客户端-服务器系统中，“向客户端询问”更多信息的服务器方法是否被认为是良好的架构？如果是这样，设计这种场景的最佳方法是什么？这有“模式”吗？
例如，假设最终用户在客户端 UI 中选择了他们想要删除的一组记录，然后客户端以该记录集作为参数对服务器进行“删除记录”调用。然后服务器找到那些以某种方式“特殊”的记录的子集，因此需要用户确认。服务器是否适合以某种方式“回调”客户端到称为“确认记录”的方法，同时仍继续从客户端到服务器的原始调用？
那么更复杂的服务器调用可能需要服务器和客户端之间的长时间“对话”呢？
某种回复说“记录 x、y 和 z 未被删除，请使用I_RELLY_WANT_TOset 重试以删除它们”对我来说似乎是一个合理的解决方案。
一般模式；不要问，做事并报告，让客户决定下一步做什么。这可以作为对话形式在持久连接的上下文中完成。
不是我的领域，所以...添加 64mg NaCl
客户端正在发送要删除的文件列表，对吗？只需让服务器回复一个成功状态列表，指出哪个文件被删除，哪个文件没有被删除，也许，为什么它没有被删除（不存在，没有权限等）。
如果常见的情况是所有文件都已成功删除，则可能会在响应开始时使用状态字段指示是否所有文件都已删除，或者客户端是否需要实际评估状态代码以查看操作的进展情况。
有了这个响应，客户端应该能够更新它对服务器状态的看法，至少关于已选择删除的文件（即，从 UI 中删除那些已成功删除的文件，以及那些不再存在；另外，可能指示服务器由于缺少相应权限而无法删除的那些文件）。
像这样的回调会颠倒客户端和服务器的角色。在许多这些类型的架构中，客户端没有能力监听请求。如果是这样，您将开始关注 P2P 类型的系统。也许这样的事情可能会奏效。
client code:
special_records = server.deleteRecords(records)
server.deleteSpecialRecords(special_records)
server code:
def deleteRecords(records):
special_records = detectSpecialRecords(records)
reply(special_records)
actuallyDeleteRecords(records - special_records)
因此，第一次调用 deleteRecords 将返回这些需要显式删除的特殊记录的列表。希望这可以帮助。
我觉得这样的安排完全没问题。没有什么可以阻止服务器向客户端回复查询以获取更多信息并让客户端提供它。只要套接字连接打开，您就可以自由支配来回发送消息。
我见过一种安排，客户端向服务器发送消息，然后在服务器控制它时，它只是在标准输入/输出和本地计算机上的文件系统之上的一个小层。它工作得很好，而且速度非常快。