为什么Angular为HttpClient使用Observable？

依照

通常，一个可观察对象可以随时间返回多个值。一 HttpClient的observable始终发出一个值，然后 完成后，再也不会发射

---

确实如此，一旦请求完成，Http请求/响应就不能产生更多的值。那么，HTTPClient在发出请求时返回可观察对象的主要原因是什么？这仅仅是因为我们可以在可观察对象上应用大量运算符（重试、去盎司等）？或者我遗漏了任何其他具体原因？

以保持API的一致性。例如，不需要引入承诺。无论如何，可观察的比承诺更灵活。此外，observable可以跟踪其订户。在HttpClient的情况下，一旦出现订阅，就会进行调用。如果您不订阅http呼叫，将不会发出请求

---

这就是为什么如果你多次订阅1个observable，就会发出多个请求。

你会找到的最佳答案是，在2015年12月的一个专门问题上，有人解释说：“observable对http有意义吗？”（但请随意阅读，很多其他答案也很好！）

在我的头顶上：
-重试
-取消
-享受所有Rxjs运营商的乐趣
-将它们合并为流的可能性
-在整个应用程序中进行反应性思考
-一致性

---

-可观察对象本质上是冷的，如果您想稍后触发它，无需将它们像承诺一样包装到工厂函数中

可观察对象是Angular框架中的标准异步处理程序

按照标准，我的意思是异步管道、路由保护、路由解析器、组件事件发射器和许多其他地方都支持可观察性

Angular团队已经投入了大量的努力来支持承诺，作为许多这些特性的后备方案，但在幕后，这些承诺只是转换成了可观测的

通过观察Http请求，Angular团队在核心中进行异步操作，与其他地方的操作一致

与承诺相比，可观察性仍然有一些优势，但这主要是基于个人观点（如我自己的观点）

• 您可以轻松地在服务中混合Http请求和WebSocket，并将API公开为可观察的。该服务的消费者将不知道其中的区别
• 您可以轻松地将对数组的Http请求转换为单独发出每个项的可观察对象。这使得向不同的消费者发送数据变得更加容易
• 如果承诺没有被正确地拴在一起，就有可能破裂。这些常见的bug通常是通过可观察的对象来避免的

---

以保持API的一致性。例如，不需要引入承诺。不管怎么说，观察比承诺更灵活。这是一场持续的争论。实际上，归结起来就是：api的一致性，可以观察到，但不能承诺。