变长嵌套路径的restapi设计

我需要为嵌套在一个或多个名称空间下的资源设计一个API

例如：

   / +
     |
     +--- namespace1 
                |
                +-------- namespace2
                             |
                             +---------------- resource

其中我可能有0到N个名称空间

建议用什么方式来表示这种资源？我曾考虑过以下方法：

表示URL中的命名空间路径。e、 g:

GET /resources/namespace1/namespace2/resource

• 优点：我觉得这是最可读的
• 缺点：在OpenAPI（3.0）和一些框架DSL中，这种方法仍然存在一些问题。此外，名称空间位于“资源”下感觉有些不对劲

将命名空间表示为查询参数：

GET /resources/resource?context=/namespace1/namespace2

• 优点：易于在开放API和DSL中声明
• 缺点：在我看来，有点吵

将命名空间表示为标头：

GET /resources/resource
Context: /namespace1/namespace2

• 优点：易于在OpenAPI和DSL中声明，噪音小于#2
• 缺点：不确定我是否喜欢隐藏在标题中的名称空间

对于这样的问题，有没有推荐的方法，或者有没有我可能缺少的其他模式？

我同意，#1是最可读的，如果您使用的技术使其易于使用，那么值得考虑。然而，这可能会导致客户端的工作，以正确地形成API调用，这不会使API特别容易发现或记录

#3实际上只是#2的一个变体。您只选择在标头中表示名称空间，而不是查询参数。在这两种情况下，它都不会使客户机必须组装URI，但是客户机可能更愿意发送一个“干净”的URI请求，而不是加载项头

像“范围”、“上下文”、“名称空间”和“层次结构”这样的东西都适合作为查询参数。这使得#2尽管你有所保留，但还是很美味

---

这看起来像是一个案例。REST并没有专门介绍这个案例。

对于我来说，不清楚如何回答这个问题。您没有写任何关于资源和名称空间是如何关联的，或者是否希望使用RESTAPI管理这些关系的内容。只需提及，您的web资源和域实体之间不必有1:1的关系。您可以拥有比域实体少得多的web资源，这取决于您的RESTAPI想要支持什么。这更像是web资源*HTTP方法和操作之间的1:1关系。因此，首先我要澄清，如果我是你，我有什么行动。