如何在RESTAPI中处理长/复杂ID

我正在设计一个RESTAPI作为推送通知服务的后端。实际推送通知将通过Firebase Cloud Messenger（FCM）处理

因此，外部客户端需要能够使用FCM ID订阅我后端中的某些对象

我的第一次尝试是

• GET/subscriptions/{deviceId}-获取订阅列表
• PUT/subscriptions/{deviceId}/myObject/{objectId}-订阅id为objectId、类型为myObject的对象（订阅类型为body）
• DELETE/subscriptions/{deviceId}-删除我的所有订阅

然而，这有两个问题。两者都连接到从FCM发送的设备的形式：

其中一个非常实用：deviceToken可以（而且确实）包含冒号。我们使用WS02API管理器作为API网关。它与路径参数中的冒号不同——在请求未到达底层API的情况下，您从网关获得“未找到”。URL编码冒号没有帮助

另一个更具理论性：谷歌没有在任何地方指定FCM ID的最大长度。（请参阅）它的长度可以达到4k，这比URL允许的长度要长：）实际上，目前它似乎不到200个字符

我提出了以下选择：

• Base64编码ID并在URL中使用。两端似乎都有不必要的额外工作，对长度没有帮助
• 将其设置为查询参数而不是路径参数。就休息原则而言，似乎并不完全“正确”，而且对长度也没有帮助
• 将GET和DELETE请求放入POST（或PUTs），并在正文中使用deviceId，在URL末尾使用

  ：GET

  或

  ：DELETE

  。据我所知，这是通过REST发出命令的一种相当常见的方式（这可能也是WS02API管理器在解析路径时担心冒号的原因）。对于DELETE似乎有点错误，对于GET则非常错误。但解决了这两个问题
• 我想另一个选择是生成我自己的ID，从最初的看跌期权返回，但这似乎也不对。引入了一个额外的数据元素，用于在两端跟踪，以绕过URL限制

---

还有其他想法吗？有什么建议吗？人们是如何处理REST URL中过长或复杂的ID的？

您的API设计得很好。API消费者不会关心您使用哪个ID，因此如果您想继续使用REST，您的第四个要点可能是最干净的。你说“那似乎不对”，尽管我看不出有什么问题。FCM ID不是对象的资源密钥。它是一个用于特定目的的订阅ID：订阅。如果您的头不受FCM ID作为资源ID的影响，这在我看来是错误的，那么您也可以自由地看到问题的最简单解决方案：）谢谢。我想我觉得没有必要强迫客户机跟踪两个ID以及它们之间的关系，而不是一个ID。我希望客户能够说“我希望在这里发送这种类型的消息”，就这样。但我明白你的意思。然而，尽管有缺点，我还是选择了Base64路线。这主要是由于项目限制——它不需要API之外的重新设计。不过，我以后会再讨论这个问题