PHP 基于 SW-X 框架,搭建高性能API架构(三)

简介: 在SW-X中,Restful组件是对API返回值结构的封装支持。\x\Restful类支持定义返回值的结构、Code->Msg关联、返回值强类型转换、抛出的数据类型转换、响应的请求头定义(跨域支持)。

前言

官网地址:SW-X框架-专注高性能便捷开发而生的PHP-SwooleX框架

希望各大佬举起小手,给小弟一个star:https://github.com/swoolex/swoolexlex


1、什么是Restful组件

在SW-X中,Restful组件是对API返回值结构的封装支持。

\x\Restful类支持定义返回值的结构、Code->Msg关联、返回值强类型转换、抛出的数据类型转换、响应的请求头定义(跨域支持)。


2、Restful的设置

API返回值的使用,主要依赖/restful/config.php配置项目,初始化默认配置如下:

<?php
return [
    // 返回值类型 支持 json|xml
    'type' => 'json',
    // 默认的返回值格式
    'default' => [
       'force'  => true, // 是否强制返回值 int|double|null类型转换
         'status' => 'code', // 状态码字段名
         'tips'   => 'msg',  // 描述字段名
         'result' => 'data', // 结果集字段名
         'set'    => [], // 默认结果集
         'headers' => [], // 响应头,可用于跨域设置(v2.5.23版本前支持)
    ],
]

其中default为默认的数据结构,当我们不使用\x\Restful::make('新的下标')指定新的返回值结构时,默认使用该结构,如果我们需要设置新的返回值结构,只需要复制default的数组结构,将下标改为新值即可。

同时,/restful/目录下还存在一个default目录,该目录是对应default默认的返回值结构,用于存放code状态码和msg状态说明。

如果设置了新的数据结构,则需要复制default目录,并重命名为对应的下标名。

下面我们来看下default目录下的两个文件:

Code状态码,/restful/default/code.php

<?php
// 状态码管理
return [
    'ERROR' => 0, // 默认失败状态码
    'SUCCESS' => 1, // 默认成功状态码
];

在实际应用时,我们只需要通过\x\Restful::状态码键名()的方式来读取对应的状态码值,例如使用SUCCESS的状态码就用\x\Restful::SUCCESS()

Msg说明,/restful/default/msg.php

<?php
// 状态说明管理
return [
  // 默认错误状态码对应的tips
  'ERROR' => [
    'default' => '请求失败', // 默认值
  ],
  // 默认成功状态码对应的tips
  'SUCCESS' => [
    'default' => '请求成功', // 默认值
    'test' => '测试msg',
  ],
];

状态码说明是一个二维数组,一维下标需要对应状态码的下标,同时必须存在一个名为default的二维下标。

这样设计的初衷是由于,在实际应用中,同一个状态码可能存在多个不同的说明,这样就可以通过指定下标读取对应的说明,当不指定时,读取default下标。

例如:

<?php
use x\Restful;
// 读取的就是SUCCESS['default']说明,默认使用default
Restful::code(Restful::SUCCESS())->callback();
// 指定msg下标,读取的就是SUCCESS['test']说明
Restful::code(Restful::SUCCESS())->msg('test')->callback();


3、Restful组件的更多示例

<?php
use x\Restful;
// 自定义msg内容
return Restful::code(Restful::SUCCESS())->setMsg('把我抛出了,没用到msg.php里的配置')->callback();
// 自定义抛出类型
return Restful::type('xml')->code(Restful::SUCCESS())->callback();
// 设置抛出的数据集
return Restful::code(Restful::SUCCESS())->data([
  'user_id' => 1,
  'username' => 'SW-X',
])->callback();
// 设置跨域支持
return Restful::code(Restful::SUCCESS())->header([
  // 接口跨域设置
  'origin' => '*',
  // 接口数据请求类型
  'type' => '',
  // 接口跨域允许请求的类型
  'methods' => 'POST,GET,OPTIONS,DELETE',
  // 接口是否允许发送 cookies
  'credentials' => 'true',
  // 接口允许自定义请求头的字段
  'headers' => 'Content-Type,Content-Length,Accept-Encoding,X-Requested-with, Origin, api_key',
])->callback();


4、在控制器中使用Restful的简单示例

接回上一篇文章,我们修改shop/select.php路由对应的控制器代码:

<?php
namespace app\http\v1_0_1\controller\shop;
use x\controller\Http;
// 引入Restful组件
use x\Restful;
class select extends Http
{
    public function index() {
  // Restful组件抛出接口响应
  return Restful::code(Restful::SUCCESS())->data([
            'user_id' => '1',
            'username' => 'SW-X',
        ])->callback();
    }
}

输出结果:

{
  "code": 1,
  "msg": "请求成功",
  "data": {
    "user_id": 1,
    "username": "SW-X"
  }
}


5、枚举

如果你不习惯Restful组件风格管理API接口返回值的话,SW-X还支持Enum枚举定义的方式。

枚举类必须继承至\design\Enum基类,官方建议统一定义在/box/enum/目录下,但不强制要求。

下面我们就在该目录下,创建一个ShopEnum类,代码如下:

<?php
namespace box\enum;
// 必须继承枚举基类
use design\Enum;
class ShopEnum extends Enum {
    /*
     * 错误异常
    */
    const ERROR = 500;
    /**
     * 正常请求
    */
    const SUCCESS = 200;
}

注意上面的注释风格,其注释内容,就是状态码对应的MSG内容。


6、枚举类的使用示例

<?php
use box\enum\ShopEnum;
// 获得对应的Msg内容
echo ShopEnum::get(ShopEnum::ERROR);
// 组装成code-msg-data的数组结构(该3个字段名都是系统固定的)
ShopEnum::get(ShopEnum::ERROR, [
    'data' => [
        'user_id' => 1
    ]
]);

结果集:

array(3) {
  ["code"]=>
  int(500)
  ["msg"]=>
  string(12) "错误异常"
  ["data"]=>
  array(1) {
    ["user_id"]=>
    int(1)
  }
}

自定义数据结构:

$ret = [
  'code' => ShopEnum::ERROR,
  'msg' => ShopEnum::get(ShopEnum::ERROR),
  'data => [],
];


7、在控制器中使用枚举的简单示例

接回上一篇文章,我们修改shop/select.php路由对应的控制器代码:

<?php
namespace app\http\v1_0_1\controller\shop;
use x\controller\Http;
// 引入自定义枚举类
use box\enum\ShopEnum;
class select extends Http
{
    public function index() {
  $array = ShopEnum::get(ShopEnum::ERROR, [
      'data' => [
      'user_id' => 1
           ]
  ]);
  return $this->fetch(dd($array));
    }
}

输出结果:

array(3) {
  ["code"] => int(500)
  ["msg"] => string(12) "错误异常"
  ["data"] => array(1) {
    ["user_id"] => int(1)
  }
}


相关文章
|
26天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
1月前
|
数据采集 监控 前端开发
二级公立医院绩效考核系统源码,B/S架构,前后端分别基于Spring Boot和Avue框架
医院绩效管理系统通过与HIS系统的无缝对接,实现数据网络化采集、评价结果透明化管理及奖金分配自动化生成。系统涵盖科室和个人绩效考核、医疗质量考核、数据采集、绩效工资核算、收支核算、工作量统计、单项奖惩等功能,提升绩效评估的全面性、准确性和公正性。技术栈采用B/S架构,前后端分别基于Spring Boot和Avue框架。
|
23天前
|
存储 分布式计算 关系型数据库
架构/技术框架调研
本文介绍了微服务间事务处理、调用、大数据处理、分库分表、大文本存储及数据缓存的最优解决方案。重点讨论了Seata、Dubbo、Hadoop生态系统、MyCat、ShardingSphere、对象存储服务和Redis等技术,提供了详细的原理、应用场景和优缺点分析。
|
2月前
|
人工智能 前端开发 JavaScript
前端架构思考 :专注于多框架的并存可能并不是唯一的方向 — 探讨大模型时代前端的分层式微前端架构
随着前端技术的发展,微前端架构成为应对复杂大型应用的流行方案,允许多个团队使用不同技术栈并将其模块化集成。然而,这种设计在高交互性需求的应用中存在局限,如音视频处理、AI集成等。本文探讨了传统微前端架构的不足,并提出了一种新的分层式微前端架构,通过展示层与业务层的分离及基于功能的横向拆分,以更好地适应现代前端需求。
|
23天前
|
消息中间件 缓存 架构师
关于 Kafka 高性能架构,这篇说得最全面,建议收藏!
Kafka 是一个高吞吐量、高性能的消息中间件,关于 Kafka 高性能背后的实现,是大厂面试高频问题。本篇全面详解 Kafka 高性能背后的实现。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
关于 Kafka 高性能架构,这篇说得最全面,建议收藏!
|
29天前
|
监控
SMoA: 基于稀疏混合架构的大语言模型协同优化框架
通过引入稀疏化和角色多样性,SMoA为大语言模型多代理系统的发展开辟了新的方向。
36 6
SMoA: 基于稀疏混合架构的大语言模型协同优化框架
|
1月前
|
存储 SQL Apache
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
Apache Doris 是一个基于 MPP 架构的高性能实时分析数据库,以其极高的速度和易用性著称。它支持高并发点查询和复杂分析场景,适用于报表分析、即席查询、数据仓库和数据湖查询加速等。最新发布的 2.0.2 版本在性能、稳定性和多租户支持方面有显著提升。社区活跃,已广泛应用于电商、广告、用户行为分析等领域。
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
|
28天前
|
API PHP 数据库
PHP中哪个框架最适合做API?
在数字化时代,API作为软件应用间通信的桥梁至关重要。本文探讨了PHP中适合API开发的主流框架,包括Laravel、Symfony、Lumen、Slim、Yii和Phalcon,分析了它们的特点和优势,帮助开发者选择合适的框架,提高开发效率、保证接口稳定性和安全性。
49 3
|
1月前
|
XML JSON API
【PHP开发专栏】PHP RESTful API设计与开发
随着互联网技术的发展,前后端分离成为Web开发的主流模式。本文介绍RESTful API的基本概念、设计原则及在PHP中的实现方法。RESTful API是一种轻量级、无状态的接口设计风格,通过HTTP方法(GET、POST、PUT、DELETE)操作资源,使用JSON或XML格式传输数据。在PHP中,通过定义路由、创建控制器、处理HTTP请求和响应等步骤实现RESTful API,并强调了安全性的重要性。
25 2
|
1月前
|
监控 安全 应用服务中间件
微服务架构下的API网关设计策略与实践####
本文深入探讨了在微服务架构下,API网关作为系统统一入口点的设计策略、实现细节及其在实际应用中的最佳实践。不同于传统的摘要概述,本部分将直接以一段精简的代码示例作为引子,展示一个基于NGINX的简单API网关配置片段,随后引出文章的核心内容,旨在通过具体实例激发读者兴趣,快速理解API网关在微服务架构中的关键作用及实现方式。 ```nginx server { listen 80; server_name api.example.com; location / { proxy_pass http://backend_service:5000;