RESTful 风格下，一个 Action 需要对多个资源操作要如何理解？

[ifane]

比如前端有一个按钮，这个按钮表示「去结算」，这个「去结算」代表了后端需要执行一系列的操作：更新订单资源，创建该订单对应的物流资源，更新用户余额。

这个系列的操作如果交由前端来逐个调用：先调用 A 接口表示更新订单，A 成功返回 200 再调用 B,B 成功返回 200 再调用 C.
感觉这样实现不太合适。

[582033]

你这属于事务处理了吧, RESTful 应该避免同时对多个资源进行访问的吧. 有关事务还是需要避免使用 RESTful 的.

提供个参考链接:
https://stackoverflow.com/questions/2346964/if-transactions-over-rest-are-unachievable-how-can-rest-ever-be-really-useful

如果有误,欢迎楼下指正

[lookas2001]

别太死板，变通一下。
如果说就是更新一个或几个东西的信息，那标准的 restful api 就可以解决，各大对象存储就是这种情况。
如果说需要多个操作，不想多发请求或者说是很复杂的逻辑或者说是干脆就没有什么资源就是一堆计算。
那创建一个 POST /do-someting 的 api 又如何呢？

[lihongjie0209]

公开数据接口我见过 rest, 但是内部业务接口就算了吧, 用几个动词想描述所有的业务需求那就是在开玩笑

[jasonyang9]

MVC 的话应该放到 Controller 里面去做吧？

[feiyuanqiu]

关于 restful，看 paypal 的指南就够了

https://github.com/paypal/api-standards/blob/master/patterns.md#complex-operation-composite

[leoli]

可以重新定义资源，资源不一定是数据库里一张表的数据吧。

[est]

发明 RESTful 的人就是个做外包忽悠人的。世界上对资源操作的行为这么丰富，非得必须封装成对资源的增删改查，还仅限这四种？有病。

[FrankFang128]

这就是 order#update 吧

[lolizeppelin]

直接返回异步任务 ID 和预计完成时间

异步任务结果有统一数据结构

到达时间点就通过异步任务 id 去拿结果

[lolizeppelin]

按照一般设计 后端这个系列操作应该 rpc 出去
让一个专门负责这类操作的服务去做

[TommyLemon]

RESTful 只适合对单表的单个操作，在 10 年前还是个好东西，一套标准减轻了前后端的沟通成本。
随着互联网的飞速发展，需求越来越复杂，对单表的单个操作这种需求就越来越少，
RESTful 已经不适用了，而且前后端关于接口的沟通问题也越来越严重。
github.com/TommyLemon/APIJSON/wiki


APIJSON 自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果，
期间自动校验权限、结构、内容，自动防 SQL 注入。

通过自动化 API，前端可以定制任何数据、任何结构！
大部分 HTTP 请求后端再也不用写接口了，更不用写文档了！
前端再也不用和后端沟通接口或文档问题了！再也不会被文档各种错误坑了！
后端再也不用为了兼容旧接口写新版接口和文档了！再也不会被前端随时随地没完没了地烦了！

在线解析
自动生成文档，清晰可读永远最新
自动生成请求代码，支持 Android 和 iOS
自动生成 JavaBean 文件，一键下载
自动管理与测试接口用例，一键共享
自动校验与格式化 JSON，支持高亮和收展

对于前端
不用再向后端催接口、求文档
数据和结构完全定制，要啥有啥
看请求知结果，所求即所得
可一次获取任何数据、任何结构
能去除重复数据，节省流量提高速度

对于后端
提供通用接口，大部分 API 不用再写
自动生成文档，不用再编写和维护
自动校验权限、自动管理版本、自动防 SQL 注入
开放 API 无需划分版本，始终保持兼容
支持增删改查、模糊搜索、正则匹配、远程函数等

后端接口和文档自动化，前端(客户端) 定制返回 JSON 的数据和结构！
创作不易，GitHub 右上角点 Star 支持下吧，谢谢^_^
github.com/TommyLemon/APIJSON

[learnshare]

RESTful 用来描述接口，包括 URL、method 和 data 等信息，与后端和数据库没有关系
你讲的这一系列操作应该由后端处理，对前端来说只是一个动作

[micean]

@TommyLemon 哪都能看到你……

[slince]

和数据库三范式一样，适当反 restful 时可以接受的，一个正常的系统都是兼顾二者的

## 反 restful

post: `/orders/checkout`

## restful 风格

上面有人提到资源不一定是数据表；将“结算”抽象成资源，

post: `/checkouts`

[slince]

@est 你们这是狭隘的理解 restful

[est]

@slince 我觉得 GET 读 POST 改就够了。何必分那么多。

GET /order/status
GET /order/list

POST /order/submit
POST /order/cancel
POST /order/close


RESTful 还区分资源的单数复数，真是没事儿找事儿。

[visonme]

一个操作涉及多个资源，相应这些资源不可能是独立而没有关联的，相反可能还存在某种包含关系，比如订单根订单项还有价格表的关系。

如果这样，不妨找到聚合根，一个入口对聚合根操作，实现多个资源联动

[jswh]

restful 的资源是抽象资源啊，又不是对应数据表的资源。看你怎么抽象了，自圆其说。

[bk201]

前端爲什麽要涉及多個接口,本身設計就有問題,一個接口就是增加結算接口

[passerbytiny]

用户需求、UI 对象、Restful 资源（可以理解为远程接口资源）、业务对象、数据库表，这几个中，任意两个之间都是不一样的，任何试图将它们进行一一映射的措施都必定会失败，任何试图将它们进行一一映射的想法必然是 S B 的。

按钮「去结算」是 UI 对象“某个按钮”。