时间戳

首页 > 解决方案 > 根据 Restful 实践，REST API 端点中的 URI

api - 根据 Restful 实践，REST API 端点中的 URI

问题描述

我计划为我们的 REST API 提供这些端点。

  1. PUT /tenant/:tenantId/users/save/:username

  2. POST /tenant/:tenantId/users/invite

  3. 获取 /tenant/:tenantId/users/fetch

  4. GET /tenant/:tenantId/users/fetch/:username

  5. PATCH /tenant/:tenantId/users/activate/:username

  6. POST /tenant/:tenantId/groups/save/

诸如保存/获取/激活之类的动词是从一致性的角度来看的。这些 RESTFul 是否符合 REST 原则？如果有的话，应该如何改变这些？有什么建议吗？

标签： apirestmicroservicesmulti-tenantendpoint

解决方案

根据此REST 资源命名指南：

RESTful URI 应该引用作为事物（名词）的资源，而不是引用动作（动词），因为名词具有动词没有的属性——类似于资源具有属性。

并且

不应使用 URI 来指示执行了 CRUD 功能。URI 应该用于唯一标识资源，而不是对它们进行任何操作。应该使用 HTTP 请求方法来指示执行了哪个 CRUD 功能。

因此，让我们以您的第一个 URI 为例

PUT /tenant/:tenantId/users/save/:username

在这里，您使用动词save。如前所述，您不应该在 URI 中指示 CRUD 操作，在这种情况下使用 POST 会更合适。这是每个 HTTP 动词用途的指南。知道了这一点，我认为例如，对于这种情况更合适的 URI 将类似于

POST /tenants/:tenantId/users/:username

在这种情况下：

GET /tenant/:tenantId/users/fetch

GET /tenant/:tenantId/users/fetch/:username

您应该删除fetch，因为您已经通过 GET 动词告诉您正在获取数据。第 6 个例子也是如此。

但是，这并不意味着您不能在 URI 中使用动词，实际上有一个特定的类别称为控制器，如同一指南中所述：

控制器资源对程序概念进行建模。控制器资源就像可执行函数，有参数和返回值；输入和输出。使用“动词”来表示控制器原型。

这个控制器资源可能会很好（我假设），例如你的

GET /tenant/:tenantId/users/activate/:username.

但我认为动词激活应该放在最后：

GET /tenant/:tenantId/users/:username/activate

推荐阅读