当我意识到我正在使用 openapi-generator 在非小型的服务导向项目中创建客户端调用存根时，我开始怀念 J2EE EJB。要让我怀念 EJB 实在是很难的事。我想向有经验的开发者和工程师们请教。这是否是业界普遍存在的盲点，人们仍然渴望并乐于在远程、客户端、单元测试、端到端测试、ORM、API 模式等不同地方对同一件事进行12种不同的描述，同时却感觉比<插入任何单体应用>更高效？
源讨论大多数 RESTful API 其实并不真正符合 REST原帖 564 条评论 · 导入时统计Fielding 赢得了这场战争，恰恰因为他思想上不连贯，而且大部分时候是错误的。这是 21 世纪的“更差的是更好的”。 RPC 系统以难以使用而闻名，最多也只是勉强成功。例如 Sun RPC、RMI、DCOM、CORBA、XML-RPC、SOAP、Protocol Buffers 等。 人们说这不是 RPC，但我们一直在写像这样的 JavaScript 函数： const getItem = async (itemId) => { ... } 这会执行 GET /item/{item_id}，而在后端我们有一个函数，看起来像 Item getItem(String itemId) { ... }，并有一些注释说明如何将 URL 映射到 item 调用。所以这就是 RPC，但不是那种高度复杂、逻辑上连贯但笨拙、让开发者作呕的系统，而是一个更手动的系统，但有很多灵活性，让开发者感觉他们掌控着一切。其中 80% 的问题在于人们...…
完整原文把你的经验，加入这段讨论。
我见过一些系统，其中团队试图避免重复，采用单一的模式源来自动生成其他部分，但通常这种做法更脆弱，更难以维护，因为管道的不同部分由不同的团队负责，且有不同的运行时间表。此外，进入这些环境并弄清楚如何安全地进行更改和部署也变得困难。有时，重复反而更简单。
完整原文并不是我们喜欢这样，只是其他大多数解决方案太过复杂且难以维护，因此重复其实并不是一件太糟糕的事情。 不过，我确实对FastAPI印象深刻，这是一个Python框架，它将API实现、数据类型和生成swagger规范很好地结合在一起。我仍然需要自己处理集成测试，但用pytest这很容易。 所以有一些解决方案可以帮助避免模式重复。
完整原文我得先离开一下，去发明另一种与语言无关的IDL来定义API，而它只在你需要的5种语言中的2种中实现。 我在开玩笑，但我确实实际上在内部实现了基本上类似的东西。我们从TypeScript文件开始，因为它的类型系统很适合描述JSON。然后我们转到JSON Schema进行验证，再转到我们需要的其他语言。
完整原文根据我的经验，当项目开始时，所有这些层都有相同的数据模型，看起来每次都要重复很多样板代码来描述“同样的东西”在每一层。 但是，随着项目的演进，你实际上会发现这些模型在不同层中存在特定的差异，尽管它们大部分是相同的，而将它们维护为{公共模型} + {差异}会比直接承认它们只是不同的相关模型要困难得多。 一些非常常见的差异的例子： - 不同语言所需的不同的基本类型（尤其是SQL vs MDW vs JavaScript） - 不同层所需的不同的框架或语言特定的注释（public/UNIQUE/需要以大写字母开头/@Property） - 在不同层需要的额外附加数据（计算属性，显示样式） - 对象关系…
完整原文我一直渴望一种简化的gRPC。我喜欢*.proto文件格式，而且原则上我喜欢使用遵循明确定义规范的代码生成来构建客户端库的想法。我喜欢让API负责定义自己的错误代码，而不是试图复用和过度使用传输协议的错误代码和语义。我喜欢消除关于参数应该放在URL中、查询参数中还是某种blob负载中的猜测和分析瘫痪。我喜欢有一个明确定义的规范，用于查询API的端点和消息格式。我喜欢明确的向前和向后兼容规则。我喜欢在不同规范之间显式支持重用通用的标准化消息格式。 但我不喜欢对字段编码格式的微观管理，也不喜欢HTTP3流式传输的东西…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。