“发送 HTTP(S) 请求”简单操作可以做什么？
Q: “发送 HTTP(S) 请求”简单操作是否有实际用途？
A: 是的，有。 多个应用程序和服务正在提供基于 HTTP 的接口（使用 HTTP 协议作为传输方式的接口）。 可与“发送 HTTP(S) 请求”一起使用的 Web 应用程序/服务类型示例包括
- RESTful 网络服务
- 支持 XML-RPC 的应用程序
- 某些基于 SOAP 的服务
下面我们列出了此类服务的几个示例和典型用例。
向即时通讯工具发送通知
许多即时通讯工具（IM，例如 Skype、ICQ、Viber、WhatsApp 等）提供 REST API，允许将消息发送到相应的消息流（频道、房间、聊天等——取决于使用的信使）。 注意：要查找 Messenger 是否支持合适的 API，请访问其站点。 通常，您会看到类似“开发人员资源”或“API”的内容，其中包含所需信息。
示例：打开 Telegram 站点并将其主页滚动到底部。 您将看到“API”链接：
如有疑问，您可以联系我们的技术人员。 支持学习，IPHost 是否可以向特定信使发送警报。
用例：我们已经提供了向多个 IM 发送警报的说明，即
请随时建议我们将更多 IM 添加到列表中。
向通知服务发送消息
通知服务允许以编程方式触发多种事件类型； 任何能够对 API 调用、电子邮件、短信等做出反应的东西都可以通过这种方式触发。 通知服务示例：Amazon SNS、Apple Push Notification Service、Google Firebase Cloud Messaging。 在使用此类服务之前，您可能需要自己建立一个 REST 端点（在相应的服务描述中阅读更多内容）。
用例：对于 Amazon SNS，可以通过使用“发送 HTTP(S) 请求”来实现以下目标：
- 发送邮件：发送邮件消息到订阅相应SNS主题的地址； 请注意，您不需要明确指定要使用的电子邮件地址：这可以被视为邮件列表
- 发送推送通知：SNS 可用于在移动设备上制作应用程序以接收通知； 因此，监控事件可以快速出现在订阅的移动设备上
- 对数据库运行查询：可以将记录添加到数据库，即使它本身没有可由 IPHost 直接访问的接口。 例如，可以向数据库添加一条记录，允许在查询所提到的数据库的网站上显示服务的状态。 其他可能的用途：通知天气状况、安全区域的温度变化等
请注意，单个 SNS 主题可以同时触发上述所有操作（以及许多其他操作）。
管理托管资源
某些托管服务提供商（例如 Digital Ocean、CloudSigma、Vultr——仅举几例）提供基于 HTTP 的 API，允许管理托管资源（例如，启动或停止虚拟机、管理存储、控制防火墙访问）。 还有一些知名的应用程序套件（例如 OpenStack、WHM/CPanel）在全球范围内被许多托管服务提供商用来设置和管理托管资源——它们也可以通过基于 HTTP 的 API 进行控制； 因此可以通过“发送 HTTP(S) 请求”简单操作来管理。
用例：使用上述与托管相关的 API，可以通过“发送 HTTP(S) 请求”实现以下目的：
- 启动备份服务：例如，如果邮件（SMTP）服务器出现故障，则可以使用警报操作启动备份服务来替代发生故障的服务
- 暂停使用过多带宽的虚拟站点帐户：如果监视器报告托管站点的带宽消耗超过特定阈值，则可以暂时暂停该站点，使其管理员能够找到并修复资源使用率高的原因
- 如果监视器检测到证书接近到期日期，则可以续订站点 SSL 证书，它可以请求续订（使用 LetsEncrypt 等服务）
可以有许多其他用途，这取决于监视的资源以及正在使用的托管管理工具/平台。 请注意，还应使用其他简单操作（那些发送电子邮件或其他消息的操作）来警告负责监视事件和对其自动响应的人员。
发布到博客
大多数流行的博客引擎都支持使用 XML-RPC 或 REST API 对内容进行远程控制（例如发布新内容）。 最流行的博客平台（引擎）支持：WordPress、Blogger（Google 支持的博客平台）、LiveJournal 和其他使用 LJ 代码库的服务； Movable Type、Tumblr、Typepad 等。大多数“微博”（如 Twitter、Pump.io 支持的服务、Plurk 等）也可以使用。
这可以允许创建通用的“服务健康”帖子； 请密切注意您在帖子中包含的数据，以避免泄露太多信息（如果您发布的博客是公开的）。
用例： 警报（“帖子”）可以作为 Twitter 直接消息、微博帖子、对 WordPress 帖子的评论以及所用博客引擎允许的各种其他内容类型发送。 将此类服务发布到公共时间表上毫无意义； 另一方面，发布到私人（直接）消息可以是一个额外的通知渠道（特别是如果收件人使用移动设备）。
运行维护任务
如果网络设备没有按预期方式运行，也许是时候对其执行维护任务了。 在某些情况下，简单的重启即可解决问题，而某些设备可能需要更复杂的操作集。 注意：使用警报脚本完全自动化网络设备重启可能是一个非常糟糕的主意； 运行检查（反过来可以提醒管理员）是更好的主意。
上述托管服务提供商的 API 允许创建快照、运行备份任务等； 但是，由于这些操作也可能导致潜在的服务中断，因此运行检查和通知管理员等应用程序级操作更为可取。
用例：一些可以使用“发送 HTTP(S) 请求”完成维护任务的示例：
- 如果网络设备支持基于 HTTP(S) 的 API，请重启网络设备； 例如，重新启动 WiFi 接入点、网络路由器、VoIP 服务等。
- 创建站点备份副本：大多数 CMS（内容管理系统，例如 WordPress）支持通过基于 HTTP(S) 的 API 运行自动备份/自检。 运行备份创建和/或自检是对资源可用性突然变化的良好响应
- 对数据存储运行检查：如果资源无法响应，则可以查询备份服务是否有相关资源的新备份； BorgBackup、Acronis 等备份服务支持能够执行此类任务的 API
一般的经验法则是：针对处于问题状态的资源运行的操作不应导致可能升级警报。 因此，应该首选非破坏性操作（检查完整性；如果不会导致资源中断，则创建备份）。
配置网络设备
如今，网络上可用的资源利用各种方式来提高它们的可用性。 负载平衡、使用多宿主和类似技术提供了更高的生存硬件或软件故障的机会。 然而，在某些情况下无法实现完全自动化，需要的动作可以从外部触发。
用例包括以下典型情况：
- 切换到备用 Internet 连接 可用于自动响应无法访问的多宿主环境的网关地址。 当可以使用备用连接时，可以通过不同的线路到达相应的网络设备，并指示将其用作默认网关。 应注意确保误报，避免不必要的切换。
- 如果现有公共 IP 变得不可用，则可能需要为设备分配另一个 IP 地址。 大多数现代托管设施都提供了更改分配给设备的 IP 地址列表的可能性。 例如，丢失 keepalive PING 请求会触发分配另一个没有连接问题的 IP 地址。
请注意，网络重新配置也会破坏正常的设备功能，因此应格外小心（并且仅在非关键或冗余设备上使用）。
