如何设计具有正确语义的restful API？

Question

例如，当向用户出售订阅时 - 系统将做的是

• 创建一个组织
• 创建用户
• 创建订阅
• 创建身份验证
• 创建并发送电子邮件。
• 更多基于业务逻辑的操作

以上所有内容都需要作为工作单元在同一数据库事务中发生。

在 SOAP 语义中，它可以抽象为寄存器（组织、用户、计划、身份验证详细信息。更多参数），并返回订阅对象。

但是在Restful World中，我们只会用HTTP动词处理资源（URL中只有名词），我发现很难描述这样的业务相关逻辑，而不是简单的CRUD？

Answer 1

事实上，您认为使用RPC模式;-）

对于REST，您必须考虑使用资源和表示。您要做的是添加订阅，因此我建议使用实现注册的方法＜code＞POST＜code＞为订阅提供一个列表资源。在请求有效负载中，您将提供订阅所需的信息，并返回有关创建订阅的提示。

以下是请求的示例：

POST /subscriptions/
{
    "organization": {
        "id": "organizationId",
        "name": "organization name",
        (...)
    },
    "user": {
        "lastName": "",
        (...)
    }
}

下面是响应的示例：

{
    "id": "subscriptionId",
    "credentials": {
        (...)
    },
    (...)
}

您可以注意到，有效负载是建议，可能与您的订阅、用户，...结构。所以请随意修改它们。

希望它能帮助你，蒂埃里

Answer 2

RESTFUL接口不要求它们1:1映射到API后面的数据库。

你的逻辑可能是:

client -- POST: SubscriptionRequests(request) --> Server
client <-- RESPONSE: Status|Error   --  Server

成功后，Status 响应可能包含包含生成的新条目的 URI 的属性。例如：SubscriptionURI = “Subscriptions/ID49343” UserURI=“Users/User4711”。

然后有人可以稍后询问活跃订阅：

client -- GET: Subscriptions               --> Server
client <-- RESPONSE: Subscriptions | Error --  Server

这个方案可以被认为是RESTful。服务器必须操作数据库（客户端不可见）以及它如何操作这一事实没有问题。

与执行SubscriptionRequest操作之前相比，订阅资源（以及用户资源）上的后续GET操作也不会产生不同的输出。

也没有令人信服的理由来创建一个更健谈的界面，只是因为你碰巧有一定的数据库建模在后面。< br >从这个意义上说，如果您创建了这样的API，情况会更糟:

client -- POST: Users(newUser)    --> Server
client <-- RESPONSE: Status|Error -- Server
(if adding user worked bla bla ... )
client -- POST: Subscriptions(userId,other data..) --> Server
client <-- RESPONSE: Status|Error  -- Server

这基本上意味着您没有设计API，只是简单地复制了数据库表的结构（下周将更改）。

总之，API设计的业务不是关心实现如何处理数据库。如果您需要事务，或者如果您使用其他方法来确保所有需要完成的事情都已完成，则取决于SubscriptionRequests的实现。POST处理程序。