Зачем Laravel-разработчики создают избыточные API ресурсы?

Какие преимущества и недостатки использования API ресурсов в Laravel для преобразования моделей в массивы, особенно если они не требуют никакой дополнительной обработки и могут содержать большое количество ключей? Насколько оправдано использование этого подхода в реальных проектах, и какие альтернативные варианты могут быть рассмотрены?
  • 12 февраля 2024 г. 10:49
Ответы на вопрос 2
В Laravel, API ресурсы используются для преобразования моделей и коллекций моделей в JSON-ответы. Они помогают контролировать и форматировать вывод данных, которые отправляются клиентской части приложения (например, веб-фронту или мобильному приложению). API ресурсы особенно полезны, когда вам нужно сериализовать модели Eloquent в нужный формат JSON.

Давайте разберемся в преимуществах и недостатках их использования:

**Преимущества использования API ресурсов:**

1. **Стандартизация ответов:** API ресурсы предоставляют единообразный способ структурирования ответов, что облегчает поддержку и развитие API.

2. **Гибкость:** Они позволяют легко добавлять и изменять структуру данных, которую вы хотите показать, без изменения основных моделей.

3. **Работа с отношениями:** API ресурсы упрощают возвращение данных, включая отношения между моделями (например, автор и его публикации).

4. **Тонкий контроллер:** Логика представления данных перемещается из контроллера в ресурс, делая контроллер более "тонким" и чистым.

5. **Управление изменением API:** За счет использования ресурсов можно контролировать, какие данные видит клиент, даже если модель изменяется; клиентскому коду, возможно, не придется меняться, если изменения в API ресурсе останутся совместимыми.

**Недостатки использования API ресурсов:**

1. **Перегрузка:** API ресурсы могут добавлять дополнительную сложность и перегрузку, если ваш API достаточно прост и не требует дополнительной логики или форматирования данных.

2. **Производительность:** В больших проектах с большим количеством ключей и сложными отношениями может возникнуть проблема производительности из-за необходимости обработки каждого элемента.

3. **Когнитивная сложность:** В проектах, где API ресурсы могут быть избыточны, они добавляют еще один уровень абстракции, который разработчику нужно понять и поддерживать.

**Использование API ресурсов в реальных проектах**:
Использование API ресурсов в реальных проектах оправдано в тех случаях, когда вам нужно изолировать домен логики вашего приложения от специфики данной сериализации и предоставления данных. Также оно целесообразно, когда вы хотите иметь возможность менять структуру данных, возвращаемых API, без изменения внутренней структуры ваших моделей.

**Альтернативы API ресурсам**:
Если API ресурсы кажутся избыточными, можно рассмотреть следующие альтернативы:

1. **Переопределение метода `toArray()` в модели:** Можно определить ваши собственные правила сериализации напрямую в модели.

2. **Вспомогательные функции:** Вместо API ресурсов можно использовать вспомогательные функции или сервисы для форм
если нет никакой дополнительной обработки, то ведь можно просто сделать $model->toArray()?
Можно, но а) тогда какие-то контроллеры будут возвращать массив, а какие-то ресурс и б) когда дополнительная обработка понадобится, нужно будет искать в коде все эти $model->toArray() и заменять их на ресурс.
Проще сразу сделать "правильно", несмотря на то, что это "избыточно" - это и называется архитектурой кода.

P.S. Но лично мне ларавелевские ресурсы не нравятся своей перемудрёностью и я использую простые DTO для этих целей.
Похожие вопросы