主要观点：不喜欢 RESTful 原则和 API，认为其存在诸多缺陷，有替代方案更适用于某些用例。
关键信息：

• 格式问题：REST 的默认格式 JSON 虽人类可读但浪费网络带宽或消耗 CPU 进行压缩解压，有更优的二进制协议如 Protocol buffers、Avro、Thrift 等，且默认使用二进制格式可减少问题。
• 缺乏契约：静态类型有诸多优势，而 REST 缺乏契约标准，文档多为样本请求和响应，消费者易耦合且易因未记录的更改而中断。
• 发布 URIs：主张仅暴露根 URI，通过 HATEOAS 发现其他信息，这种方式虽符合规范但速度慢且易出错，Swagger 标准却坚持固定 URIs。
• 不支持批量等操作：原生不支持批量请求、分页等企业级功能，有多种竞争建议但都存在问题。
• CRUD 导向：面向 CRUD 而非业务或事务，很多业务情况难以简单用 CRUD 描述，处理域事件时 API 设计尴尬。
• HTTP 动词描述不足：从业务术语映射到 HTTP 动词繁琐，世界更丰富，REST 限制了对业务域的表达。
• 混合 HTTP 状态码与业务回复：用 4xx 类状态码表示业务错误不合适，错误码设计初衷不是用于丰富的业务，导致编码复杂。
• 时间耦合：基于 HTTP 的 RESTful API 存在时间耦合问题，请求-响应模式在很多情况下并非最优，消息驱动架构更可靠，REST 也无单向请求概念。
• 缺乏标准：没有标准，只有相互矛盾的实践，难以确定如何正确与 API 交互。
• 向后兼容性：处理向后兼容性的方式存在缺陷，如只添加字段、内容类型版本控制、HTTP 重定向等，设计并非为演进考虑。
• 替代方案：在考虑性能、是否需要阻塞请求-响应、持续部署等情况下，可选择更合适的技术，如更紧凑格式、消息队列等。

重要细节：文中通过多个具体例子和对比，如与 SOAP、XML 的比较，以及各种技术的优缺点阐述，详细说明了 RESTful 的缺陷和替代方案的优势。