Question

我有一个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}

这就是我现在这样做的方式。如果将UID作为UUID，则没有机会（通过设计UUID）任何uri可以针对不同的资源存在两次。但我仍然不确定这是否是在独立资源和分区数据之间进行折衷的正确方法。

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

Answer 1

由于您的用户ID是全球唯一的，因此我找到了

/user/{id}

和

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

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

你写道：

我的ID是UUID，所以URL会变得非常快，并且看起来不那么好看（如果这算作一个参数:)）

不完全是:)）

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