mysql - 正确使用 REST 设计 - 类别和子类别

Question

我有两个关于基本 REST 概念的问题。

问题 1:类别

所以我有一个要从数据库中显示的类别列表。

从类别中选择*

目前，我使用此 REST 设计:/api/v1/categories/

这样合适吗？

我还看到了 /api/v1/categories/list/ —— 或者这是首选？ (如果是这样，那么简单的 /categories 调用会显示什么？(或者正确的方法是 /api/v1/category/list where category 是单数，添加 list 将显示所有类别 - 这样，调用 /category 将允许仅查看其中一个类别的信息？)

问题 2:子类别。 (将“Seinfeld”视为“电视”的子类别。)

从子类别中选择 *"WHERE Category_id = {id}

上面的 id 可能是我想要列出特定节目的电视类别。

我是否需要对具有 subcat_id 的子类别执行 /api/v1/categories/{id}/ 操作？我是否必须使用参数，例如 /Categories?id={id}/

这种关系如何运作？

Answer 1

我的回答基于“务实的 REST”。

QUESTION 1: Categories

如果您使用复数或单数形式，那么我建议坚持使用它，而不是在单数和复数之间跳转......这是主观的。

如果您使用单数形式，那么 list 路径操作听起来适用。如果你使用复数，那么我认为它更主观......恕我直言 list 消除了歧义，我更喜欢它。

QUESTION 2: Subcategories. (Think "Seinfeld" as a subcategory of "Television".)

恕我直言，子类别听起来像是一个单独的资源。我认为它应该有自己的路径元素。

Would I do /api/v1/categories/{id}/ for the Subcategory with the subcat_id? Would I have to use parameters instead like /Categories?id={id}/

我认为 /api/v1/subcategories/{id}/ 更受欢迎。但越来越流行的一件事是搜索标准。 ID 可能只是众多搜索条件之一。如果您发现自己添加了搜索条件，则 /api/v1/subcategories/?id={id} 或 /api/v1/subcategories/?filter={some_search_string} 其中您决定如何解析该搜索字符串。

要考虑的最重要的事情是您能够在不改变您现在做出的这些初始决策的情况下扩展(扩展)您的 API。添加到 API 很容易，但一旦使用现有的 API 设计就很难改变。