7

我知道以前有人问过这类问题。我有我的问题的解决方案，我想知道我是否在任何地方破坏了 REST 或 HTTP 主体。

在我的系统中，我有一个名为的资源member，它支持通常的GET/POST/PUT操作。成员的状态为Active和Disabled。我需要对禁用用户的操作进行建模。我理解为什么从 REST 的角度来看跟随是一个坏主意

POST api/member/john.smith/disable

我已经阅读了接受代表禁用成员请求的资源的解决方案，如下所示

public class DisableMemberRequest
{
    public string Username {get; set;}
}

然后是POST上面的资源

POST api/DisableMemberRequest

虽然这种方法听起来很合理，但我觉得这在干净的 API 接口方面是不正确的。200 OK上述请求的响应是否应该是 a或是值得商榷201 Created的202 Accepted。

我在想，我会创建一个名为的新资源DisabledMember，并且PUT该资源上的 a 意味着应该禁用特定成员，如下所示

PUT api/disabledmember/john.smith

从 REST/HTTP 的角度来看，这在我看来是一个完全有效的设计。但我不是专家，我想与长期从事这项工作的人一起验证这一点。

编辑

在与此页面上的其他程序员互动后，我正在添加这些详细信息。禁用成员的过程不仅仅是在成员上设置状态标志。当成员被禁用时，还需要触发其他工作流。

4

5 回答 5

4

我喜欢做这样的事情的一种方法是定义一个表示禁用成员集的资源。要禁用成员，请将该成员添加到禁用成员集中。它可能看起来像这样。

POST /api/DisabledMembers
Content-Type: text/uri-list

http://example.org/api/members/john.smith

如果你想反转操作，你可以做

POST /api/ActiveMembers
Content-Type: text/uri-list

http://example.org/api/members/john.smith

这种方法的好处是，做事GET /api/DisabledMembers是一件非常自然的事情。此外，通过使用text/uri-list它可以很容易地同时禁用/重新激活一组成员。

于 2013-06-22T00:30:23.920 回答
3

您的前两个建议都有点味道，因为它们在 URL 中有一个动词。良好的 RESTful 架构仅定义类名词资源，因为 HTTP 协议定义了适用于这些资源的动词集。

另一个建议很有趣，但PUT建议您然后可以执行 aGET来获得您刚刚放在那里的东西的表示，这在这种情况下没有多大意义。

从您所说的来看，启用或禁用用户帐户有一个重要的过程，并且您不喜欢将值从to简单地“翻转”到的PUTor操作。如果这需要一些时间，具有瞬态并且可能是您希望能够向 API 使用者公开的东西，以便他们了解该过程，那么将过程本身定义为一种资源是有意义的：PATCHtruefalse

开始停用：

POST api/members/deactivations

获取停用的当前状态或报告已发生的活动：

GET api/members/deactivations/john.smith

取消正在进行的停用（可选）：

DELETE api/members/deactivations/john.smith

如果您可以重新激活一个帐户，它可能会遵循类似的模式。

如果您觉得这些工作流程没有足够的实质内容来证明它们是他们自己的资源，或者您只是不知道该做出什么回应GET，那么它表明工作流程不是那么重要，以至于它不能简单对 API 用户隐藏并作为更改用户值的副作用触发active。

于 2013-06-21T23:39:26.897 回答
2

刚刚在这里回答了一个类似的问题。

思考或应用 REST 作为起点（至少它对我有用）的实际方法是按照以下方式思考：

1) 仅使用 HTTP 'GET/POST/PUT/DELETE' 作为对域 'actions' 建模的方式。就像您处理数据库时一样，您的所有操作都映射到CURD。

2) URI/URL 仅用于标识资源。您的 URI 中不应有任何“操作”。

3) 交换的数据应该在 HTTP 消息的正文中。只是为了简化讨论，而不是讨论如何对数据本身进行建模

Tragedian 的解决方案看起来很干净。

更新以解决@Suhas 的评论

REST 与命名约定无关。这完全是关于在设计 REST API 时如何考虑资源而不是“操作”。应该始终考虑 URL/URI 中的“Nonce”之类的资源。您已经拥有域操作应映射到的所有 CURD 操作，并用于操作 URL 中的资源。

我喜欢 Tragedian 的解决方案，只是为了讨论，我们可以用一组类似的 nonce 和不同的 URL 模式重构 Tragedian 的解决方案，以“更好地”适应不同的域使用。以下可能不是该领域的最佳解决方案，但它们等效于 RESTful。

移除成员资格

  • 删除 api/membership/[member-id]/

获取会员状态

  • 获取 api/membership/[member-id]/status/

添加会员

  • POST api/membership/[member-id]/

更新以解决“DisabledMember”作为资源的问题

如果按照 Suhas 的建议使用“PUT DisabledMember”执行“禁用成员”，那么对“DisabledMember”资源的以下操作意味着什么？

DELETE DisabledMember → 再次激活？？

POST DisabledMember -> ??

GET DisabledMember – 这很简单☺</p>

通过这种设计，它实际上“伪装”了资源中的“禁用”操作。你可能仍然可以强迫它做你想做的事，但它对我来说不会那么安宁。

于 2013-06-22T03:28:09.683 回答
0

If it's a short process to disable the user, why not use HTTP PATCH?

See this answer to a similar question

于 2013-06-22T03:51:17.730 回答
0

成员的状态为 Active 和 Disabled

所以状态是成员实体/资源的属性；在那种情况下，为什么您不想在状态设置为已禁用的成员资源上使用简单的 PUT 方法？

于 2013-06-21T23:22:52.897 回答