最近使用Express服务器搭建一个RESTful API服务器,
之前看过一些 RESTful API的例子以及最佳实践, 但是在实现多层嵌套的API的时候, 发现很违背易用性: 就拿 post - comment 为例: 我想得到通过comment的id来得到它的详情
/api/posts/:postID/comments/:commentsID
但是在现实世界中, 知道commentID来获得comment并不需要依赖postID... 有时候前台请求comment的时候 只知道commentID,并不知道它对应的postID. 所以这样设计API是否不合理?
后来我改成了
/api/posts/:postID/comments/ - 用于POST comment, GET comments
/api/comments/:commentsID/ - 用于单个comment的CRUD
但是这样设计的话 Comments这项业务要分成两个Router 业务也不是很顺
所以应该怎么样设计 才比较合理?
@Kaijun p 这个思路是不错，在处理的路由时，会有冲突 GET /api/comments?postID=XXXX - 获取某个Post下所有comments GET /api/comments - 获取Post列表
GET /zoos：列出所有动物园 POST /zoos：新建一个动物园 GET /zoos/ID：获取某个指定动物园的信息 PUT /zoos/ID：更新某个指定动物园的信息（提供该动物园的全部信息） PATCH /zoos/ID：更新某个指定动物园的信息（提供该动物园的部分信息） DELETE /zoos/ID：删除某个动物园 GET /zoos/ID/animals：列出某个指定动物园的所有动物 DELETE /zoos/ID/animals/ID：删除某个指定动物园的指定动物
刚看了下StackOverflow上各种帖子 比如这个
有的人认为应该是我后来设计的这样
/api/posts/:postID/comments/ - 用于POST comment, GET comments
/api/comments/:commentsID/ - 用于单个comment的CRUD
有的人认为 comments 脱离posts存在
GET /api/comments?postID=XXXX - 获取某个Post下所有comments
POST /api/comments/ - 新的Comment, 但是Body中要带有postID.
GET /api/comments/:commentsID/ - 用于单个comment的GET
有点启发 感觉第二种更加, 不知道各位怎么想?