我将REST API设计为推送通知服务的后端。实际推送通知将通过Firebase Cloud Messenger（FCM）
处理
因此，外部客户端需要能够使用其FCM ID订阅我的后端中的某些对象。
我的第一次尝试就像是
- GET / subscriptions / {deviceId} - 获取订阅列表
- PUT / subscriptions / {deviceId} / myObject / {objectId} - 订阅id为objectId的对象，类型为myObject（订阅类型为body）
- DELETE / subscriptions / {deviceId} - 删除我的所有订阅
然而，这有两个问题。两者都连接到FCM的deviceToken形式：
- 一个非常实用：deviceToken可以（并且确实）包含冒号。我们使用WS02 API Manager作为API网关。它在路径参数中不喜欢冒号 - 你得到一个＆＃34;未找到＆＃34;从没有请求的网关到达底层API。对冒号进行URL编码没有帮助
- 另一个更理论化：Google不会在任何地方指定FCM ID的最大长度。 （参见this answer）所以它可能长达4k，这个URL允许的时间更长:)实际上，目前它似乎不到200个字符
我提出的选项：
- Base64对ID进行编码并在URL中使用。在两端似乎没有必要的额外工作，并且对长度没有帮助
- 将其设为查询参数而不是路径参数。并不完全正确＆＃34;正确＆＃34;在REST原则方面，并没有帮助长度
- 使用正文中的deviceId和URL末尾的
:get或:delete将GET和DELETE请求发送到POST（或PUT）。据我所知，这是通过REST发出命令的一种相当常见的方式（也许可能是为什么WS02 API管理器在解析路径时担心冒号）。对于DELETE来说似乎有点错误，对于GET来说非常错误。但是解决了这两个问题。
- 我想另一个选择是生成我自己的ID，从初始PUT返回，但这似乎也不对。引入一个额外的数据元素来跟踪两端只是为了绕过URL限制。
还有其他想法吗？有什么建议？人们如何处理REST URL中过长或过多的ID？