从 Dingo API 原理来看 Laravel 的 Http 请求处理过程

?赞

Transformer 是我最喜欢的功能

@Summer 大神早~

手动点赞?

这里呢我其实遇到一个 Transformer 的问题，两位有谁遇到过这个场景嘛？
https://github.com/dingo/api/issues/986

@Summer @oustn

如果 issues 里没有描述清楚，我再复述一下：
预期：通过 dingo 返回的所有字段都是 snake 的

额 不能编辑嘛，不小心就回车了 ?

实际：dingo 的 Transformer 有一个 include 功能，该功能是用来灵活配置 Transformer 的包涵关系的，在 Transformer 中可以设置 protected $defaultIncludes 和 protected $availableIncludes 来进行关联处理，这里的 include 是要求传入模型的方法名的，根据 PSR-2，方法名是 CameCase 这个是必然的，所以我以 EmployeeTransformer 举例：

class EmployeeTransformer extends TransformerAbstract
{
    protected $defaultIncludes = ['department', 'employeeCategory', 'employeeStatus'];

    ……
}

这样我的到的结果

{
    "data": {
        "id": 1, 
        "name": "竺珺", 
        "department": {
            "data": {
                "id": 3, 
                "name": "市场部"
            }
        }, 
        "employeeCategory": {
            "data": {
                "id": 2, 
                "name": "实习"
            }
        }, 
        "employeeStatus": {
            "data": {
                "id": 1, 
                "name": "在职"
            }
        }
    }
}

预期：通过 dingo 返回的所有字段都是 snake_case 的, 如下：

{
    "data": {
        "id": 1, 
        "name": "竺珺", 
        "department": {
            "data": {
                "id": 3, 
                "name": "市场部"
            }
        }, 
        "employee_category": {
            "data": {
                "id": 2, 
                "name": "实习"
            }
        }, 
        "employee_status": {
            "data": {
                "id": 1, 
                "name": "在职"
            }
        }
    }
}

如果是 Laravel，我知道在 Model 中有个 snake 的开关，所以使用 toArray 方法即可全部转化，但是在 dingo 中我翻遍了手册和 issues，没有找到答案，源码也看了一部分，在看源码过程中发现了 https://github.com/dingo/api/issues/986 提到的方法，但我看代码，那根本不是作者刻意留的，算是个小漏洞。

迫于进度压力就没有继续跟进代码研究了，我目前没有找到行之有效的方法，我是通过创建 BaseTransformer 覆写 Dingo TransformerAbstract 类的方法才实现的，你们有更好的方法吗？

     /**
     * 覆写原方法，增数组键转换为 snake_case 的函数
     *
     * @param Scope  $scope
     * @param mixed  $data
     * @param array  $includedData
     * @param string $include
     *
     * @return array
     */
    protected function includeResourceIfAvailable(
        Scope $scope,
        $data,
        $includedData,
        $include
    ) {
        if ($resource = $this->callIncludeMethod($scope, $include, $data)) {
            $childScope = $scope->embedChildScope($include, $resource);
            // 此处增加 snake_case 转换
            $includedData[snake_case($include)] = $childScope->toArray();
        }

        return $includedData;
    }

当然，还有一种方法是在模型中将关联方法改为 snake 的或者拷贝一个 snake 形式的功能相同的关联函数。

@springjk 都有 transform 了为啥还要自行车，非要用那个 $defaultIncludes，灵活性太低了 ~~ 实际上这个是 league/fractal 这个包的锅，dingo 没有处理 transform 部分，只是写了个 adapter .

想想别的招，别用那个$defaultIncludes， 在transform 方法 return 数组中可以直接写。。记得在查找时 with 预加载。

return [
    ......
    'employee_category' => $model->employeeCategory,
    'employee_status' => $model->employeeStatus
];

而且你没觉得通过$defaultIncludes这种方式获取的数据 那个 data key 很讨厌么？想想你在前端要获取的时候 还要额外写个 data 属性。。。

employee.employeeCategory.data.name

如果要使用 transform 也很简单，手动调用 transform 方法就行

return [
    ......
    'employee_category' => (new EmployCategory())->transform($model->employeeCategory),
    'employee_status' => $model->employeeStatus
];

@Summer 也挺喜欢的，不过就是发现有个问题，这样我得为每个接口定义一个transformer类，这样看起来好像有点多余，好像没有发现可以共用的方法

@oustn 你讲的方法不错，不过在做了判断后和 include 差不多，是一个备选方案。fractal 的文档我在看 dingo 的时候也看过，这里面也没讲到这个问题，那个 data 的确实很讨厌很讨厌，但是确实是有用的，比如有时候 meta 里是有一些信息的，另外我对 include 的灵活性问题持不同意见，include 的意义我认为是用来让接口功能更灵活，由客户端决定到底需要什么样的数据，这样可以应对不同的业务需求。

举例：

• /api/users 返回所有用户
• /api/users?include=posts 返回用户列表及其文章列表
• /api/users?include=postCount 返回用户列表与其文章总数
• /api/users?include=department 返回用户列表与其部门详情
• /api/user/1?include=posts,orders 返回用户详情与其文章列表和订单列表

需要说明的是：

1. 如果有的路由会因为 include 的参数很多或者很常用，可以 alias 一个简单的路由
2. 对于某些基本上每个地方都要用到的 relation 可以设置为 defaultIncludes
3. 特别复杂的接口就不要这样玩了

个人认为以上的方法可以灵活的应对各种端或者各种场景下需要接口返回不同的结构信息的需求，让接口不需要因为频繁的前端需求而做变更。

如果像你讲的方式来做，这样就把接口返回定死了，可能只适合需求稳定、前端/移动端/PM 都讲道理的情况下，针对各种接口要求并且不想做聚合接口做冗余接口时，我认为这个 include 的设计挺好的。

@Someant transformer 如果你像我在上面一样用了 include，可能就不需要定义那么多了，另外，很多字典表结构都是一样的，返回数据也只有个name等，我一般都是定义一个字典表来转换通用的表结构。

class DictionaryTransformer extends BaseTransformer
{
    public function transform(Model $model)
    {
        return array_only($model->toArray(), ['id', 'name']);
    }
}

mark

看完你的文档，搞的我又翻了一遍dingo/api的细节。真是又有收获呢。
dingo为了拿到kernel的protected属性middleware竟然连反射都用上了，真是很Hack。