README

(Beta) MyAPI - 组件

PHP JSON-RPC 服务器和客户端，具有使用DTO自动生成和验证json-schema

安装

请等待在 sshilko/php-api-myrpc 的初始公开版本。

composer require sshilko/php-api-myrpc-beta

兼容性

• PHP >= 8.1

为什么选择RPC

多年来，JSON从2007-2010年开始流行，并取代了RPC空间中的XML，成为更易于阅读和浏览器/JavaScript友好的格式。为统一json rpc api的请求/响应创建了一些提案。

后来，REST 通过提供适合简单CRUD应用程序的资源端点而流行起来，但它需要更多的前期投资来设计API，随着API代码库的增长，通常在单体中添加新功能，复杂性迅速增加。

REST API和JSON-RPC API比较

• JSON-RPC类型较松散，具有OSI-4传输层
  • REST更严格，定义了OSI-7应用层
• JSON-RPC仅在合同定义中重复使用json和json-schema
  • REST可能使用多个标准，如Swagger/OpenAPI、XML、JSON、HATEOAS、JSON-LD和Hydra（Hydra是JSON-LD的扩展，本质上是一种OpenAPI标准）
• JSON-RPC没有关于缓存的说明，因为它不依赖于HTTP层
  • REST定义了关于缓存行为、端点命名、幂等的规范性要求 - 实际上，这些都没有由任何框架保证，直到开发者的具体实现
• REST api定义了用于响应的HTTP状态码，这可能导致客户端“更快”的处理
  • 在实践中，错误消息或错误跟踪通常仍在正文中发送，并由客户端解析
  • 在RPC中，我们不依赖头部或cookie，错误消息格式在标准中有记录，错误日志和响应/传输是不同的关注点，不应混淆

TLDR REST需要良好的技术和领域知识来设计合适的API，强制实施严格的实现规则。GRPC开始时需要较少的准备，提供输入和输出的类型化模式验证，实现灵活。

在2022年，JSON-RPC总体上发展成了Google gRPC

• 两者都是二进制格式（要么是HTTP1或HTTP2压缩）或者包装在MsgPack中的json-rpc
• 两者都是严格类型化的，json-rpc需要手动模式验证（库关注点）
• 两者都为客户端提供了一些自动生成的模式，以构建API合同

JSON-RPC可能没有gRPC那么普及，但它更简单易用

• 更容易采用
• 与HTTP一样可靠（网络保证），HTTP可在任何移动/网络/物联网设备上使用
• 所有现有的HTTP工具都可以在开发过程中重用（初始JSON优势）
• 如果已经实现了JSON-RPC，则可以轻松采用REST、gRPC或Swagger（很少相反情况）
• OpenAPI v3 Swagger几乎与JSON-RPC兼容

此库的最佳用例是什么

• 外观模式用于业务逻辑
• 以简洁为焦点，不是一种通用的解决方案
• 最小化第三方依赖
• 无需编译
• 为客户端自动生成JSON-Schema

范围之外

此库无意成为框架，为了保持焦点并最小化代码库，它不提供

• HTML或其他易于导航API的方式，这可以通过第三方json-schema转换器实现
• 非基于JSON的API，此实现侧重于JSON表示
  • 支持其他包装/格式，请贡献您的实现
• 授权、认证、安全或其他组件，这些对于完整的面向用户的应用程序是必需的

请重用最适合您需求的现有解决方案。

为什么这个库存在

• APIPlatform 过于复杂，需要长期承诺，
  • 高度依赖Doctrine和Symfony
  • 大型代码库，具有隐藏的复杂性和可维护性问题
• zendframework/zend-json-server 已被遗弃且不灵活
• API-first应用程序中始终需要具有I/O验证的简单外观模式
• 利用PHP8提供的严格类型I/O的强大功能，并具有标准错误消息
• 简单、快速、易于阅读和扩展以满足您的需求，易于迭代和贡献

未来路线图

• 1.0稳定版发布

贡献

• 请阅读贡献文档

作者

Sergei Shilko contact@sshilko.com