Question

我们目前正在设计内部REST API。我们有以下用例：

用户（109）想要阅读他已经发送给另一个用户（110）的消息
应用程序通过他在验证后收到的令牌凭据（在执行GET请求时）知道应用程序（109）
我们假设在该示例中，用户109是发送者，110是接收者

从用户角度总结“给我发送给我的邮件（109）已发送到110”

我们想到了以下URI，但我们无法决定采取哪种方式：

a) GET http://localhost:9099/api/mails/109?receiverUserId=110
b) GET http://localhost:9099/api/mails?senderUserId=109&receiverUserId=110
c) GET http://localhost:9099/api/mails?receiverUserId=110
d) GET http://localhost:9099/api/mails/me/to/110 (when logged in as 109 via token credentials we know that "me" is 109)
f) GET http://localhost:9099/api/mails/109/to/110 (explicit request, e.g. for admins … has to be guarded against illegal access)

所有链接都是“上下文敏感”，即发送其中一个链接到接收方（110）将产生执行GET请求的不同结果。

我想知道您对使用哪个网址的看法。

任何帮助高度赞赏。

欢呼声烫发

Answer 1

对于不同客户的不同回复，对于相同的网址是可以的。

StackExchange会这样做：

GET /me/comments/{toid}

记录在案here。

Twitter也是这样做的：

GET /statuses/home_timeline

记录在案here。

这两个网址都会根据身份验证推断登录用户。是的，如果用户共享缓存，它会失败缓存，但IMO，这没关系。这是否打破了REST的“资源识别”约束可能是有争议的。 this问题的答案以及随后的评论向我展示了为什么它有争议。

事实上，在这些选项中，您做提及不是“上下文敏感”的网址：

GET /api/mails?senderUserId=109&receiverUserId=110

此消息总是会将消息从109返回到110.但是当一个客户端希望在查看“已发送”消息时看到此结果时，另一个客户端希望在查看“已接收”消息时看到此结果。有点奇怪呃？另外，在服务器上，您必须检查经过身份验证的用户是否为109 | 110，否则抛出401 UNAUTHORIZED。

我会选择类似的东西：

GET /mail/sent

返回所有已发送的邮件。和

GET /mail/sent?to=110 (like applying a 'filter' to /mail/sent)
OR
GET /mail/sent/110 (clean URL)

返回发送到110的邮件。

Answer 2

“上下文敏感”链接对于 REST API来说是个坏主意（特别是这会妨碍缓存）。如果你只想使用HTTP，这没关系。

所以我建议使用不依赖于当前用户的URL，并根据您的规则限制对它们的访问。

Answer 3

在我看来，你需要2层：

一个是内部层，不需要用户身份验证，只能从内部组件访问。它包括像

这样的API

GET http://localhost:9099/api/mails?senderUserId=109&receiverUserId=110

该层的优点是可测试性，可重用性和可配置性。

另一层是外部层，需要用户身份验证，可从外部客户端访问。它包括像

这样的API

GET http://localhost:9099/api/mails?receiverUserId=110。

客户端必须登录才能获取令牌凭据，然后服务器可以从此令牌获取用户信息，并将外部API调用映射到内部API调用。

您可能有不同类型的身份验证方法，但内部图层不会更改，您只需将不同的外部图层映射到内部图层。

REST API设计 - 查询邮件数据 - 选择哪种毒药？

3 个答案: