请考虑我使用以下RESTful API端点:
此数据模型中的约束:帖子始终有用户。
通过"处理嵌套资源"我的意思是处理CRUD操作。
我应该在 / users / $ user_id / posts / 端点上实施CRUD操作(POST,PUT,PATCH,DELETE),还是应该创建另一个端点 / posts / 并在那里处理CRUD操作,同时保持第一个端点为只读?
很抱歉,如果这个问题已经存在于SO的另一个表格中。 :-)有这么多" FUD"围绕RESTful API。
提前感谢任何提示/澄清!
亲切的问候, ķ。
答案 0 :(得分:0)
您应该在现有/posts/
和/posts/$post_id/
端点上实施操作。很少有理由使多个端点代表相同的资源。为什么要让他们知道他们只能在/users/$user_id/posts/$post_id/
上获取,但必须转到/posts/$post_id/
才能删除?
有时,人们将其实现为
/users/: show all users
/users/$user_id/: show specific user
/users/$user_id/posts/: show all posts by user -- GET only
/posts/: show all posts -- All operations
/posts/$post_id/: show specific post by user -- All operations
他们使用/users/$user_id/posts/
作为用户帖子的非规范引用。虽然我不能称之为错误,但最好每个资源坚持使用一个端点。过滤参数并不难。
答案 1 :(得分:0)
Following Roy Fielding's clarification regarding REST我建议你不要担心网址的设计:
REST API不能定义固定资源名称或层次结构(客户端和服务器的明显耦合)。服务器必须能够自由控制自己的命名空间。相反,允许服务器通过在媒体类型和链接关系中定义这些指令来指示客户端如何构造适当的URI,例如在HTML表单和URI模板中完成的。 [这里的失败意味着客户端由于带外信息而假设资源结构,例如特定于域的标准,这是面向数据的,与RPC的功能耦合等效。]
测试API的RESTfulness的一种好方法是用统一ID替换所有精心构造的URI,并查看客户端是否可以使用此信息。如果不是你依赖带外信息,可以改善你的RESTfulness。但是类似于n度数据库规范化,你可能希望生活得更少一些正确性'为了让所有参与者更容易。需要多少正确性取决于您的域名的易变性以及您是否期望更少或更多的API用户。
如果您想对URI中的带外信息进行编码,我会尝试尽可能地限制所需的信息。由于/users/$user_id/posts/$post_id/
要求用户知道三件事(URL设计,用户ID,帖子ID),似乎有一些替代方案可以让更多的无知; - )
/posts/$post_id
:更好,因为您的用户只需要一个ID和资源类型来构建URI /$resource_id
:最好,但需要全球唯一的ID