将资源嵌套在RESTful API中很常见。例如,要检索ID = 5的公司中的员工:
GET /companies/5/employees
在REST设计中,将资源放在一个不属于公共父资源实例的公共“目录”中是否也普遍可以接受?这更像是一种“is-a”关系,我认为典型的嵌套结构具有“属于”关系中的嵌套资源。
例如,将以下两种不同的资源(内部代理,外部代理)分组是否可以接受?在这种情况下,路径的agents
部分是描述其后代但不是父资源的类别。
GET /agents/internal
GET /agents/external
没有计划使用/agents
路径添加任何资源;它仅用于分组目的。
或者这样的事情要避免吗?
GET /internal-agents
GET /external-agents
我觉得第二个选项更正确,但我喜欢的第一个选项是美学。
答案 0 :(得分:1)
鉴于您有一些agents
可以是internal
或external
:
/ agents / internal打破网址一致性是个坏主意
拥有/ agents / internal是一个糟糕的想法,它不能被使用,因为它会导致你的API中不一致的URL,人类和程序都不会轻易理解。
/resources/{resouce id}/sub-resources/{sub-resource id}/
/不应超过2个级别。
您的第一个示例/companies/5/employees
就是一个很好的例子。/agents/internal
网址会使您的API网址不一致且难以理解为人类以及程序。您可以结束GET /agents/2
,其返回ID为2的代理以及返回内部代理列表的GET /agents/internal
。相同的网址结构,但意义不同。使用一致的URL结构有助于理解语义,甚至不知道API的作用。
/ internal-agents是一个有效的想法,但要注意缺点
您有两个特定资源internal-agents
和external-agents
的想法是有效的。
但它可能有一些缺点,具体取决于确切的用例:
partner
,则必须添加新资源partner-agents
/agents
资源过滤器可能更适合此用例:GET / agents?status = internal
第三个想法是将内部和外部视为对/agents
资源上某些状态的过滤。
GET /agents
返回所有座席(内部+外部)GET /agents/2
返回ID为2的代理GET /agents?status=internal
返回内部状态GET /agents?status=external
返回具有外部状态的代理如果您添加新状态,例如partner
:
GET /agents
返回所有座席(内部+外部+新合作伙伴状态)GET /agents/2
仍会返回ID为GET /agents?status=internal
仍会返回具有内部状态的代理GET /agents?status=external
仍会返回具有外部状态的代理GET /agents?status=partner
返回具有新合作伙伴身份的代理GET /agents?status=internal,partner
返回具有内部或合作伙伴身份的代理在过滤器和特定资源之间进行选择只是一个上下文。 唯一要记住的是确保URL的一致性。