抛弃restful风格API

抛弃restful风格API

相对于 直接只用一个post请求而言，restful缺陷，画蛇添足的缺点太多了，我的个人第一直接感悟如下：

1. login 登陆 多资源一起操作，这个资源路径应该如何写；说白了，就是业务逻辑的动作方法，是很难以被抽象为资源的增删改查；

   想用对一个资源的简单CRUD的操作，也抽象出来 你真正想要的业务逻辑动作方法，我怀疑你脑袋进水了；一个业务逻辑方法往往是很多表的联合查询，联合处理，才能得出一个业务逻辑；你非要用对一个资源的CRUD来抽象出来你实际想要的业务逻辑，就是说 明明很简单的事，你要绕道地球几圈来搞，这样的垃圾人才真不少；

2. 把动作变成请求方法，要知道 RPC 或者函数栈世界里，程序的核心思想就是方法，方法就是对资源的动作，非要把动作和资源 强制分离开来，从 哲学上来说，完全脱裤子放屁，restful提出来 20么多年 火不了，是有原因的，菜鸟会人云亦云，大牛是不会这么搞的，我也没有看到 大的平台的接口是restful风格的，菜鸟太多；restful 从哲学理论上 就行不通，落地不了，我断言以后10年也落地不了；始终是一些小项目 小范围的菜鸟使用；

---

restful的缺陷 你自己去biying吧，我不赘述了：

---

以下是我问文心一言的：

restful风格不灵活，若一个接口 对多个资源进行操作 怎么写路径？

RESTful API 的设计原则鼓励对单一资源进行操作，但有时候我们确实需要在一个接口中对多个资源进行操作。这种情况下，我们可以考虑以下几种策略来设计路径：

1. 使用复数资源名称：
   如果操作涉及到同一类型的多个资源，可以使用复数形式的资源名称来表示。例如，如果你想要同时操作多个订单，可以使用 /orders/batch 或 /orders/multiple 这样的路径。

2. 使用查询参数：
   通过查询参数来指定需要操作的多个资源的ID。例如，/resources?ids=1,2,3，这样服务器就知道需要对哪些资源进行操作。

3. 使用动作作为路径的一部分：
   虽然这有点违背RESTful原则，但有时为了实用性，我们可以在路径中包含动作，如 /resources/batch-update 或 /resources/multi-delete。

4. 使用POST请求体传递资源列表：
   通过POST请求，并在请求体中发送一个包含多个资源ID的列表或需要执行的操作细节。这样，服务器可以根据请求体中的内容对多个资源执行相应的操作。

5. 创建专门的批量处理接口：
   可以设计一个专门的接口来处理批量操作，比如 /batch-operations，然后通过POST请求体来描述需要对哪些资源执行何种操作。

6. 使用任务或操作ID：
   如果批量操作是异步执行的，可以首先创建一个任务或操作，并返回一个操作ID。然后，客户端可以使用这个ID来查询操作状态或结果，例如 /batch-tasks/{taskId}。

7. 混合使用：
   你也可以混合使用上述策略，比如通过POST请求体发送资源列表到 /resources/batch-update 路径。

请注意，虽然这些方法可能不完全符合严格的RESTful原则，但在实际应用中，为了满足业务需求，有时的确需要对这些原则进行一定的折衷。重要的是保持API的一致性、可预测性和易用性。

同时，对于批量操作，务必谨慎处理，因为它们可能会对系统造成较大的负载。在设计这样的接口时，应该考虑到性能、安全和事务性等方面的问题。

---

restful 的缺陷？

RESTful风格的API设计虽然有其优点，但也存在一些缺陷。以下是对RESTful缺陷的清晰归纳：

1. 面向资源的设计限制：

   • RESTful API是面向资源的，这意味着所有操作都需要抽象为对某种资源的操作。在某些情况下，这可能会增加API设计的复杂性并降低直观性。例如，登录和登出操作在RESTful API中可能需要抽象为对“authentication”资源的操作，使用POST和DELETE方法来表示，这不如直接的方法调用直观。

2. 部分字段查询的困难：

   • 在RESTful API中，部分字段查询可能不如非RESTful设计直观。例如，按照状态查询用户可能需要创建一个特定端点或使用查询参数，这增加了API的复杂性和学习成本。

3. 监控和排障的困难：

   • RESTful API鼓励使用路径参数，这可能导致配置反向代理服务器（如Nginx）变得复杂。使用正则表达式来匹配路径参数和指定HTTP方法可能增加了配置的复杂性。

4. 可读性的降低：

   • 在RESTful API中，理解一个接口的含义需要结合HTTP方法和路径，这可能会降低API的可读性，尤其是对于不熟悉RESTful风格的开发人员。

5. 缺乏标准化：

   • RESTful API没有一套统一的标准，导致不同的开发者和组织可能有不同的实现方式和规范。这种“模糊性”给开发和维护带来了挑战。

6. 安全性问题：

   • 由于RESTful API基于HTTP协议，它可能面临一些安全性问题，如跨站脚本攻击（XSS）和跨站请求伪造（CSRF）。

7. 大量数据传输问题：

   • 使用HTTP协议进行通信的RESTful API在传输大量数据时可能会出现性能瓶颈。

8. 版本控制问题：

   • 没有统一的标准也导致了版本控制上的困难，可能会使得API的升级和维护变得复杂。

综上所述，RESTful风格虽然在一些方面有其优势，但也存在不少缺陷，需要在设计和使用时进行综合考虑。