rest - REST 服务中的建模操作

Question

我知道以前有人问过这类问题。我有我的问题的解决方案，我想知道我是否在任何地方破坏了 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 接口(interface)方面是不正确的。上述请求的响应是否应该是 200 OK 值得商榷。或 201 Created或 202 Accepted .

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

PUT api/disabledmember/john.smith

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

编辑

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

Answer 1

刚刚在 here 中回答了类似的问题.

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

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

2) URI/URL 仅用于标识资源。你的 URI 中不应该有任何“ Action ”。

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

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

更新以解决@Suhas 的评论

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

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

移除成员资格

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

获取成员(member)状态

GET api/membership/[member-id]/status/

添加成员(member)

POST api/membership/[member-id]/

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

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

DELETE DisabledMember → 再次激活？？

POST DisabledMember -> ??

GET DisabledMember – 这很简单 ☺

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