Helldar 19 мар в 11:00

Магический API Resource в Laravel

Средний

10 мин

4.1K

PHP*Laravel*

Кейс

Комментарии 9

hello_my_name_is_dany 20 мар в 06:38

Преобразование snake_case в camelCase

Или написать свою реализацию пагинации, count и items хватает вполне, фронтенд может сгенерировать ссылки, посчитать кол-во страниц и тд. К тому же получаете полный контроль на полями, можете вставить хоть ещё 1000 других. Делается это всё буквально в пару строк кода.

<?php

class SomeController extends Controller
{
    public function __construct(private Repository $repository) {}

    public function action(Request $request): Response
    {
        [$count, $items] = $this->repository->find(
            $request->query('limit', 10),
            $request->query('page', 1),
        );
    
        return response()->json([
            'count' => $count,
            'items' => $items,
            'meta' => $this->getSomeMeta(),
        ]);
    }
}

Бизнес-потребность

Очень сложно назвать изменение ответа в API бизнес-потребностью. Про поле status в HTTP API уже было много раз обсуждалось - антипаттерн. По поводу дат, обычно соглашаются на стандарт ISO, так как многие сериализаторы и библиотеки умеют с ним работать, а потребитель уже сам решает, что и как делать с этой датой в соответствии с требованиями, хочет показывает в ISO, хочет показывает в Y-m-d\TH:i, на вряд ли пользователи будут смотреть, что же там им API отдал.

По-моему, вы на пустом месте усложнили себе жизнь. Конечно, это полезно разобраться в магии Laravel и попробовать сделать ещё больше магии, но для решения бизнес-задач явно не стоит.

Amega 20 мар в 10:05

Тут мораль простая: вместо того, чтобы закапываться в магию Laravel'а, от нее надо максимально уходить. Как и в целом от фреймворка стоит максимально отвязываться, помня, что это лишь инструмент для решения проблем, а не хозяин положения, диктующий, как и что должно быть (бизнес/заказчика меньше всего будет волновать, что так и как умеет или не умеет делать фреймворк).

Helldar 22 мар в 03:24

Полностью согласен! Заходя в свою квартиру вместо того чтобы обживаться и использовать её на полную, надо максимально оградиться внутри. Желательно поставить палатку где-нибудь в углу и не выходить из неё без крайней необходимости ?

-2

Amega 23 мар в 01:02

Не очень понял вашу логическую цепочку, но статья ровно о том, как вам приходится преодолевать трудности (или даже боль), вызванные вашим же выбором "удобных" ресурсов Ларавела. Я же пишу о том, что на подобные вещи изначально не стоит завязываться. А говоря про "не выходить без крайней необходимости", на всякий случай уточню, что "не завязываться" (или "отвязываться") не тождественно "не использовать".

Helldar 23 мар в 03:31

Статья о том, как можно легко и непринуждённо изменять общую структуру респонса для всего проекта особо не напрягаясь.

При наличии инструмента было бы глупо не использовать его возможности по-максимуму. Ситуации когда проект внезапно мигрирует в другую экосистему, стремятся к нулю и само их наличие говорит либо о неправильно выбранном стеке, либо о некомпетентности тех кто это затеял.

-1

Sway 2 мая в 17:07

А в следующей версии Laravel они что-то поменяют и костыль сломается. В Laravel слишком много лишней магии, которую лучше обходить стороной если она на 100% не подходит для решения поставленной задачи. Практически любое вмешательство в магию потенциально приведет к проблемам при обновлении версии Laravel. Нет смысла копить риски если можно их исключить стабильным собственным решением, которые минимально завязано на фреймворк. К тому же такое решение всегда можно адаптировать под другие требования с минимальными затратами. И нет, я не предлагаю творить везде свои велосипеды. Тут нужно принимать решение для каждой ситуации отдельно - бороться с магией Laravel или отвязаться от неё.

Helldar 2 мая в 19:13

Или принять её и использовать без каких-либо проблем. А мажорные обновления на то и мажорные, что могут вносить критические изменения. При этом, конкретно данная механика не изменялась с 5-х версий.

Не зря поговорка есть - «волков бояться - в лес не ходить».