这些看起来与一般的 CRUD API 非常不一样，关键在于这些操作具有良好的定义 。不管对于 服务提供方 还是 客户端 来说，这样的体验都更好 。
服务提供方不再需要根据更新字段来推测业务操作的意图，业务操作清晰明了，这样的代码更简单，也更容易维护 。
而对于客户端来说，它们能执行或不能执行哪些操作也是一目了然的 。如果 API 具有良好的文档化，比如使用了 Swagger，那么就可以很清楚地了解到 API 都具有哪些约束 。
定义这样的 API 需要做一些前期思考，这不同于使用简单的 CRUD 生成器 。如果你打算将 API 暴露成公共端点，就需要在很长的一段时间内为 API 提供支持，最好还是把它看成是一个永久性的事项 。
我总是建议人们在前期多花一点时间，因为有些东西到了后面就很难修改，而 API 就是一个很好的例子 。
所以，在进行 API（REST 或其他）设计时，请停止使用 CRUD 模型 。相反，可以通过 DDD 来定义 API，包括领域对象和它们的业务操作 。
如果你想看到更多关于领域对象的例子，可以参考 Amazon Web Services 的 API 。在 AWS API 开发者指南里，每一个服务都有对应的“关键概念”一节，用以描述领域对象 。
例如，S3 里定义了 Bucket、Object 和 Permission 等领域对象，Kinesis 里定义了流（stream）和分片（shard） 。先了解一个服务的领域对象，再查看 API 参考，然后浏览服务的 API 清单 。你会发现，基于这些领域对象构建的 API 在理解和使用上都更加直观 。
英文原文传送：
http://jlhood.com/there-is-no-u-in-crud/
推荐阅读
- 金庸小说什么武功最高 降龙十八掌在金庸里面排第几
- macOS 10.15功能升级，和32位应用说再见
- 聪明的女人结婚不领证 女方为什么要先办婚礼再领证
- 去环球影城的搞笑说说 去北京环球影城怎么发朋友圈
- 中国文学史上第一部长篇历史小说 中国第一部文学史著作
- 蚕茸柱天胶囊(黄色包装)的说明书
- 生力雄丸的说明书
- 疏肝益阳胶囊的说明书
- 东阿阿胶 阿胶补血膏的说明书
- 健脾益肾颗粒(无蔗糖型)的说明书