2016-10-30 15 views
1

假设我有不同种类的对象HouseCar。现在我想添加评论。JSON-API设计

最好的做法是什么? 有终点:

/api/house/:houseId/comments

/api/car/:carId/comments

或者征求意见一般般API:

/api/comments/:generalId

+0

没有太多的API设计正规教育,我会说前者更好,因为它更结构化 - 我认为它是有一个productA.comments/productB.comments vs一个大数组注释[] –

+0

我的关注点在于,在API代码中,我从每个对象获得对comments.model的依赖关系。所以API的可读性比API代码的结构更值得吗? – Stefan

回答

4

我的产品类型是实现细节。要REST风格我会创建API与

/API /产品/的[ProductID]

此端点会询问服务GET(获取给定的产品),POST(更新指定产品),删除

/API /产品/

该终端将支持GET(获取所有的产品),PUT(创建新产品)

这个端点将支持GET(获得给定产品的给定注释)和POST(更新给定注释),DELETE(删除给定评论)。这个端点将支持GET(给定注释)。 在这种情况下,commentID可能是唯一的每个资源,而不是全局。

/API /产品/的[ProductID] /评论

该终端将支持GET(获取产品的所有评论)和PUT(创建新的注释),删除(删除产品所有评论)

API /评论/ [commentId]

此资源(与操作GET,POST,DELETE)也很好。但它需要全球独一无二的评论。如果您需要在不知道productId的情况下管理单独的评论,请随意公开此类端点。这并不违反REST。

在这个API设计中,我们为每个产品和评论分别提供资源。 我们还拥有所有产品的资源,并为给定产品的所有评论提供资源。每个资源可能支持GET,POST,PUT,DELETE。你可能ommit某些操作(例如不暴露于/api/product/[productID]/comments/[commentID]POST当你不希望支持编辑点评

编辑:。在由@lospejos评论建议你可以使用复数形式(产品,评论)无论哪种方式,你的API将是REST风格,每个帖子/评论都是独立的资源。

+1

我同意除了我会在每个端点使用复数实体:'/ products','/ comments'等 – lospejos

+0

对不起,我在这个问题上还不够清楚。产品不能只是一个端点。它更像/ api/house和/ api/car。我编辑这个问题以使其更加清晰。 – Stefan

+0

好的,所以make/api/house/[id]和/ api/car/id。或者在id中编码产品类型,如/api/house.[house-id] /api/car.[car-id]/。无论哪种方式都需要RESfull,您需要为每个独立资源分配唯一的重新编号(URL)。 –