域模型分区场景中嵌套/分层对象的REST API设计

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

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

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

/user/{id}

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

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

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

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

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

我现在就是这样做的。如果ID是UUID，那么（通过UUID的设计）对于不同的资源，任何uri都不可能存在两次。但我仍然不确定这是否是在独立资源和分区数据之间达成妥协的正确方法

---

或者我只是错过了显而易见的解决问题的方法。任何提示都非常感谢

因为您用户的ID是全局唯一的，我发现两者都是唯一的

/user/{id}

及

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

你写道：

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

不完全是：）

---

我不太喜欢你的第三种方法。服务器如何使用额外的

X-Foo-Application:{id}

头？无需标识用户，也不属于任何URI。

如果选择第一种方法，您将如何处理数据分区。您如何找到用户？第三种方法是向服务器提示该用户所属应用程序的上下文。它不是URI的一部分，因为查找用户不是必需的。头应该会给出这样的信息，不是吗？因为用户是全局唯一的，我不明白将应用程序放在URI或头中如何更容易找到用户。“查找”的确切含义是什么？假设我们有类型为Application的对象和类型为User的对象。有一个全局对象保存应用程序，每个应用程序保存用户。如果有请求进来，我想找到由URI寻址的用户。因此，我需要在每个应用程序中查找所提到的用户，或者在请求中提供更多上下文，以便知道要查找哪个应用程序

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