2

我有一个 HTTP API，假设应用程序和这些应用程序有用户。关系应用程序 - 用户是 1:m。该模型在应用程序上完全分区。这意味着应用程序是自包含的，没有供用户使用的全局池。因此，为了找到用户，我需要预先了解应用程序。

我觉得为这种情况设计合适的 REST API 并不容易。URI 通常不应该依赖于模型的实现方式。他们应该只处理资源。并且 URI 也应该尽可能短。

现在我正在考虑用户的 URI 应该是什么样子。基本上我认为最好只

/user/{id}

从外部的角度来看，这应该是好的。但是我想保持数据的分区，所以我既不想拥有一个引用所有应用程序用户的全局池，也不想在所有可用应用程序中搜索用户。这意味着我需要添加一些关于应用程序的上下文。使 URI 看起来像

/application/{id}/user/{id}

将解决问题。虽然考虑到我的模型，但这是有道理的。应用程序和用户是复合的，这意味着用户在应用程序之外没有任何意义。另一方面，我仍然认为用户可以是一个独立的资源。而且我的 id 是 UUID，所以 URL 会很快变得很长，而且看起来不太好看（如果这算作一个参数:)）

第三种选择是在 HTTP 请求中添加一个额外的标头。这就像

X-Foo-Application: {id}
GET /user/{id}

这就是我目前的做法。如果 id 是 UUID，则任何 uri 都没有机会（根据 UUID 的设计）对于不同的资源可以存在两次。但我仍然不确定这是否是在独立资源和分区数据之​​间做出妥协的正确方法。

或者也许我只是错过了明显的问题解决方法#4。任何提示表示赞赏

4

1 回答 1

1

由于您的用户的 ID 是全球唯一的，我发现两者

/user/{id}

和

/application/{id}/user/{id}

可以接受。第二条路径使用户与应用程序的关系更加清晰。但我可能会根据用户 ID 的全球唯一性选择第一条路径。

你写：

而且我的 id 是 UUID，所以 URL 会很快变得很长，而且看起来不太好看（如果这算作一个参数:)）

不完全是 ：）

我不太喜欢你的第三种方法。服务器如何使用额外的X-Foo-Application: {id}标头？不需要识别用户，它不是任何 URI 的一部分。

于 2012-11-07T11:13:16.777 回答