通知服务既需要一种提交短信的方式，也需要一条到达收件人手机的路由。选择接口只解决了问题的第一部分。
每个部分做什么？
API 接收程序化请求。网关连接你的应用程序和移动网络。
你的应用程序通过接口提交收件人、发送方和消息。网关将消息传递到负责投递的网络服务。提供商可以在一个服务中同时提供这两个部分。
SMPP 网关参考文档描述了将应用程序与移动消息中心连接的网关。它还描述了提供多种接口（包括 HTTP 和 SMPP）的网关。
接口并不决定所有投递能力。便捷的请求格式无法使不受支持的发送方在某个目的地变为有效。
我应该选择哪种接口？
除非现有的 SMPP 集成或特定的连接需求需要管理 SMPP，否则新应用应选择 HTTP。
使用 HTTP 时，你的应用程序发出请求并处理响应。但仍然需要重试、防重复发送和投递事件处理。
SMPP 使用保持打开的连接。你的客户端需要认证会话，并处理连接断开、确认和入站操作。SMPP 对此进行了说明。
已有的 SMPP 系统可以使该接口成为合理的选择。在假设另一个 SMPP 连接表现相同之前，先测试提供商支持的操作和限制。
我应该比较哪些投递能力？
根据你的应用需求，比较目的地覆盖范围、允许的发送方、吞吐量和有用的故障报告。
- Destinations: 确认你服务的每个国家都受支持，因为一条可用路由并不意味着另一条也可用。
- Senders: 在确定收件人将看到的身份标识之前，检查可用性和注册情况。
- Throughput: 区分请求限制与投递路径实际承载流量的速率。
- Events: 确认入站消息和投递失败如何到达你的应用程序。
Bird 的目的地页面发布了各国的具体要求。发送方类型说明了身份标识选项。
为什么投递与接受是分开的？
网络可以在你的提交请求完成之后才完成投递。
消息中心可以在手机不可达时暂存短信。消息中心说明了这个等待阶段。
在你的应用程序中，将提交和投递作为独立的结果处理。否则，即使后续投递报告记录了失败，已被接受的请求也可能看起来是成功的。
如何通过 Bird 的 HTTP API 发送消息？
提交一条消息，保存其标识符，然后处理随后的投递事件。
使用 POST /v1/sms/messages 并传入 to、from、text 和 category 来发送自由文本消息。将 category 设置为 marketing、transactional、authentication 或 service 之一。发送指南记录了支持的字段。
202 响应确认请求已被接受，但不确认消息已投递到手机。通过 SMS 事件跟踪返回的 id，以便最终结果更新到正确的请求。
哪条路径适合我的应用？
选择你的应用程序能够可靠运行的接口，然后单独验证投递能力。
- 如果没有特定的 SMPP 需求，新集成请使用 HTTP。
- 当现有系统或所需的连接行为需要会话管理时，使用 SMPP。
- 在将流量提交到任一路径之前，先测试目的地、发送方和投递事件。
简而言之
API 和网关承担不同的职责。
API 接收你的请求，而网关提供通往移动网络的路径。
HTTP 无需管理 SMPP 会话。
SMPP 除了消息工作流之外，还需要连接恢复和会话管理。
接受与投递是分开的。
发送请求成功并不代表收件人已收到消息。
除了接口，还要比较投递路径。
在选择集成方式之前，检查目的地支持情况、发送方要求、吞吐量和故障报告。