Api — Symfony. Организация файлов для API.


Содержание

Как создать приложение Symfony с несколькими ядрами¶

Создание приложений с несколькими ядрами больше не рекомендуется Symfony. Рассмотрите вариант создания нескольких маленьких приложений вместо этого.

В большинстве приложений Symfony входящие запросы обрабатываются фронт контроллером public/index.php , который инстанциирует класс src/Kernel.php для создания ядра приложения, загружающего пакеты и работающего с запросом лля генерирования ответа.

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

Вот наиболее распространённые случаи применения создания множества ядер:

  • Приложение, которое определяет API, может определить два ядра по причине производительности. Первое ядро будет служить обычному приложению, а второе — реагировать только на API запросы, загружая пакеты и подключая меньше функций;
  • Высокочувствительное приложение может также определять два ядра. Первое будет только загружать маршруты, совпадающие с публичными частями приложения. Второе — загружать остальное приложение и его доступ будет защищён веб-сервером;
  • Приложение, ориентированное на микросервисы, может определять несколько ядер для выборочного подключения или отключения сервисов, превращая традиционное монолитное приложение в несколько микро-приложений.

Добавление нового ядра в приложение¶

Создание нового ядра в приложении — это процесс, состоящий из трёх шагов:

  1. Создайте новый фронт контроллер для загрузки нового ядра;
  2. Создайте новый класс ядра;
  3. Определите конфигурацию, загружаемую новым ядром.

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

Шаг 1) Создайте новый фронт контроллер¶

Вместо создания нового фронт контроллера с нуля, легче будет дублировать уже существующий. Например, создайте public/api.php из public/index.php .

Далее, обновите код нового фронт контроллера, чтобы инстанциировать новый класс ядра, вместо обычного класса Kernel :

Другой подход заключается в том, чтобы оставить существующий фронт контроллер index.php , но добавить утверждение if для загрузки другого ядра, основанного на URL (например, если URL начинается с«/api«, используйте ApiKernel ).

Шаг 2) Создайте новый класс ядра¶

Теперь вам нужно определить класс ApiKernel , используемый новым фронт контроллером. Легче всего это сделать дублировав существующий файл src/Kernel.php` и внеся в него необходимые изменения.

В этом примере, ApiKernel будет загружать меньше пакетов, чем Kernel по умолчанию. Убедитесь в том, что вы также изменили локацию кеша, логов и файлов конфигурации, чтобы они не сталкивались с файлами из src/Kernel.php :

Шаг 3) Определите конфигурацию ядра¶

Наконец, определите файлы конфигурации, которые будет загружать новый ApiKernel . Следуя коду выше, эта конфигурация будет жить в одном из множества файлов, хранящихся в каталогах config/api/ и config/api/ENVIRONMENT_NAME/ .

Новые файлы конфигурации могут быть созданы с нуля при загрузке всего нескольких пакетов, так как это очень просто. В других случаях, дублируйте существующие в«config/packages/« файлы конфигурации, или, что ещё лучше — импортируйте их и переопределите необходимые опции:

Выполнение команд с другим ядром¶

Скрипт bin/console , используемый для запуска команд Symfony всегда использует класс по умолчанию Kernel , чтобы построить приложение и загрузить команды. Если вам нужно выполнить консольные команды, используя новое ядро, дублируйте скрипт bin/console и переименуйте его (например, bin/api ).

Далее, замените инстанциирование Kernel вашим собственным инстанциированием ядра (например, ApiKernel ) и теперь вы можете выполнять команды, используя новое ядро (например, php bin/api cache:clear ). Тепеоь вы можете выполнять команды, используя новое ядро.

Команды, доступные для каждого конспольного скрипта (например, bin/console и bin/api ) могут отличаться, так как они зависят от пакетов, подключенных дла каждого ядра, которые могут отличаться.

Отображение шаблонов, определённых в другом ядре¶

Если вы следуете Лучшим практикам Symfony, то шаблоны нового ядра будут храниться в templates/ . Попытка отобразить эти шаблоны в другом ядре, приведут к ошибки Не существует зарегистрированных путей для пространста имён «__main__».

Чтобы решить эту проблему, добавьте следующую конфигурацию к вашему ядру:

Выполнение тестов, используя другое ядро¶

В приложениях Symfony функциональные тесты по умолчанию расширяются из класса WebTestCase . Внутри этого класса, метод под названием getKernelClass() пытается найти класс ядра, для запуска приложения во время тестирования. Логика этого метода не поддерживает приложения с несколькими ядрами, так что ваши тесты не будут использовать правильное ядро.

Решением будет создать пользовательский базовый класс для функциональных тестов, расширяющийся из класса WebTestCase и переопределяющий метод getKernelClass() , чтобы возвращать полное имя класса ядра для использования:

Добавление большего количества ядер в приложение¶


Если ваше приложеиие очень сложное и вы создаёте несколько ядер, то лучше хранить их в собственных каталогах, вместо того, чтобы путаться с кучей файлов в каталоге src/ по умолчанию:

Эта документация является переводом официальной документации Symfony и предоставляется по свободной лицензии CC BY-SA 3.0.

Flex: Составьте ваше приложение¶

После прочтения первой части этого туториала, вы решили, что Symfony стоит ещё 10 ваших минут. Отличный выбор! В этой второй части, вы узнаете о Symfony Flex: потрясающем инструменте, который делает добавление новых функций таким же простым, как выполнение команды. Он также является причиной того, почему Symfony идеален для маленького микро-сервиса или огромного приложения. Интересно? Отлично!

Symfony: Начните с микро!¶

Кроме случаев, когда вы строите чистый API (об этом позже!), вы скорее всего захотите отобразить HTML. Чтобы сделать это, вы будете использовать Twig. Twig — это гибкий, быстрый и безопасный шаблонизатор для PHP. Он делает ваши шаблоны более читаемыми и компактными; он также делает их более дружественными для веб-дизайнеров.

Twig уже установлен в нашем приложении? На самом деле, ещё нет! И это прекрасно! Когда вы начинаете новый проект Symfony, он маленький: только самые критично важные зависимости включены в ваш файл composer.json :

Это отличает Symfony от любого другого PHP фреймворка! Вместо того, чтобы начинать с громоздкого приложения с каждой возможной функцией, которая может вам понадобиться, приложение Symfony маленькое, простое и быстрое. И вы полностью контролируете, что добавлять.

Рецепты и дополнительные имена Flex¶

Так как же нам установить и сконфигурировать Twig? Просто выполните одну команду:

Две очень интересные вещи происходят за кулисами благодаря Symfony Flex: плагину Composer, который уже установлен в нашем проекте.

Во-первых, twig — это не имя пакета Composer: это дополнительное имя Flex, которое указывает на symfony/twig-bundle . Flex разрешает это дополнительное имя для Composer.

И во-вторых, Flex устанавливает рецепт для symfony/twig-bundle . Что такое рецепт? Это способ для библиотеки автоматически конфигурировать себя, добавляя и изменяя файлы. Благодаря рецептам, добавление функций незаметно и автоматизировано: установите пакет и вы закончили!

Вы можете найти полный список рецептов и дополнительных имён, зайдя на https://symfony.sh.

Что сделал этот рецепт? В дополнение к автоматическому подключению функции в config/bundles.php , он добавил 3 вещи:

config/packages/twig.yaml Файл конфигурации, который устаналивает Twig с разумными настройками по умолчанию. config/routes/dev/twig.yaml Маршрут, который помогает вам отладить ваши страницы ошибок. templates/ Каталог, в котором будут жить файлы шаблонов. Рецепт также добавил файл макета base.html.twig .

Twig: Отображение шаблона¶

Благодаря Flex, после одной команды вы можете незамедлительно начать использовать Twig:

Расширив AbstractController , у вас теперь есть доступ к перечню методов сокращения и инструментов, вроде render() . Создайте новый шаблон:

Вот и всё! Синтаксис << name >> отобразит переменную name , которая передаётся из контроллера. Если вы новичок в Twig, то добро пожаловать! Вы узнаете больше о его синтаксисе и силе позже.

Но, прямо сейчас. страница содержит только тег h1 . Чтобы предоставить ему макет HTML, расширьте base.html.twig :

Это называется наследование шаблона: наша страница теперь наследует структуру HTML из base.html.twig .

Профилировщик: Рай отладки¶

Одна из самых крутых функций Symfony ещё даже не установлена! Давайте это исправим:

Да! Это ещё один союзник! И Flex также устанавливает другой рецепт, который автоматизирует конфигурацию Профилировщика Symfony. Какой результат? Обновите!

Видите эту черную панель внизу? Это панель инструментов веб-отладки, и это ваш новый лучший друг. Наведя на на каждую иконку, вы можете получить информацию о том, какой контроллер был выполенен, инфромацию о производительности, удачи и неудачи кеширования и многое другое. Нажмите на любую иконку, чтобы зайти в профилировщик, где вы можете получить ещё более детализированные данные об отладке и производительности!

А, и по ходу установки новых библиотек, вы будете получать больше инструментов (например иконку панели инструментов веб-отладки, которая отображает запросы БД).

Использование профилировщика просто, так как он сконфигурировал себя сам благодаря рецепт. Что ещё мы можем установить так же легко?

Богатая поддержка API¶

Вы строите API? Вы можете уже с лёгкостью вернуть JSON из любого контроллера:

Но для действительно богатого API, попробуйте установить Платформу Api:

Что мы знаем о Symfony: мифы и легенды


Когда веб-разработчика спрашивают о Symfony, у него в голове, как правило, рисуется определенная картина, некое устоявшееся мнение. Что можно сказать о Symfony в одном предложении? Это full-stack веб-фреймворк, написанный на PHP. Всё так, но это не совсем точное определение. Понятие Symfony несколько шире стандартного понимания.

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

Ребята из Noveo пообщались со своими PHP-разработчиками и выделили общие ключевые моменты, которые были отмечены, и задались вопросом, действительно ли всё так хорошо / плохо, как говорят. Так получилась эта подборка мифов и легенд о Symfony.

Низкая связность компонентов

Модульность — одна из наиболее важных особенностей работы с Symfony. Как уже было отмечено выше, Symfony являет собой набор переиспользуемых и автономных компонентов — бандлов. В Symfony всё есть бандл, и всё живёт в бандлах — и компоненты ядра фреймворка, и код вашего приложения. Такое архитектурное решение предоставляет возможность строить приложение очень гибко. Шаг за шагом вы строите свою структуру — по кирпичику, таким образом ваше приложение уже не монолитная стена, и, чтобы заменить какой-то модуль, вам не нужно рушить всё приложение. Причём конечную конфигурацию, разумеется, можно настроить «под себя». Более того, вы можете использовать отдельные компоненты Symfony вне фреймворка. Данным подходом успешно пользуются и другие проекты, например, Laravel, Drupal, Magento и многие другие.

Отдельно следует отметить поддержку Dependency Injection в Symfony как одну из главных фич фреймворка. Использование DI снижает связность и упрощает тестируемость кода.

В Symfony много готовых решений

Это действительно так — решения есть для самых разнообразных задач, от повседневных до экзотических. На сегодняшний день существует более 2500 бандлов, каждый из которых вы можете подключить и использовать — спасибо модульности. Если по каким-то причинам один из бандлов не подходит, его можно заменить на аналогичный, благо выбрать есть из чего. Или же, одновременно исправив фатальный недостаток и исполнив заветную мечту программиста, написать свой — такой же, но другой. Пожалуй, здорово иметь возможность переиспользования готовых компонентов и сторонних библиотек и в то же время не быть прибитым гвоздями к конкретной технологии или инструменту.

Цукерберг рекомендует:  Вакансии Игра платформер Мишка Косолапый

Symfony сложный

Symfony слишком сложный. Отчасти это так — у Symfony более высокий порог вхождения по сравнению с другими PHP-фреймворками. Соответственно, и времени на его освоение требуется гораздо больше. Новичкам придется непросто. Здесь и использование инновационных возможностей языка, и применение паттернов проектирования. Нужно быть готовым к тому, что изучением только Symfony дело не ограничится. В придачу следует ознакомиться с технологиями и инструментами, которые идут рука об руку с Symfony и позволят использовать его максимально продуктивно: Twig, SwiftMailer, Monolog, phpUnit, Doctrine, а также наиболее популярные бандлы, например, FOS, Knp, Gedmo и др.

Symfony спроектирован очень грамотно

Symfony отличается выстроенной концепцией и идеологией, но важно понимать, что он не даёт готового и единственно правильного решения при разработке проекта. Задача построения конечной архитектуры приложения (не забываем уважать стандарты) целиком и полностью делегируется разработчику и остается на его совести. Отсюда можно выделить два следствия, которые перекликаются с предыдущим пунктом: опытный Symfony-разработчик с большей степенью вероятности обладает глубокими знаниями языка в частности и навыками проектирования в целом. Второй, не столь жизнерадостный момент: найти грамотных Symfony-разработчиков сложнее, а воспитание собственных требует времени.

Symfony делает вас свободными

Считаете, что подключили бандлы и можно работать? Секундочку, не всё так просто. Поскольку фреймворк гибкий, то и возможностей для его настройки много. Конфиги и аннотации — наше всё. В стандартной поставке фреймворка базовые конфигурационные файлы уже присутствуют. Однако разработчики Symfony не ограничиваются yaml-файлами. Для конфигурирования приложения или отдельных его частей предоставлена возможность использовать аннотации, конфиги в виде xml- или php-файлов. Единого стиля нет, и каждый использует тот способ, который представляется наиболее удобным. Конечно, по многим моментам есть рекомендации, что использовать в той или иной ситуации, но это не накладывает на разработчиков дополнительных ограничений, они вправе самостоятельно делать выбор.

Что это — свобода или хаос? Данную ситуацию можно развернуть в любую сторону. Всё достаточно просто. Предоставляя людям выбор, вы возлагаете на них ответственность. Очевидно, что при безалаберном использовании приложение легко превратится в лоскутное одеяло, а качество продукта не будет высоким. Правильным решением будет ещё до начала активной стадии разработки договориться внутри команды о подходе к конфигурированию приложения и описанию кода. Общение — ключ к успеху.

Symfony подходит только для крупных проектов

Сложный вопрос. Symfony, если мы говорим о full-stack фреймворке, хорош для относительно крупных проектов. Пожалуй, следует согласиться с тем, что Symfony — не всегда лучший выбор для небольших проектов за несколькими исключениями. Первое — он может быть использован, если требуется решать сравнительно типовые задачи, а выигрыш за счёт быстрого старта и использования стандартных бандлов значителен. Однако в данном случае к выбору следует подходить осознанно, взвесив все преимущества и проблемы, с которыми, возможно, придётся столкнуться. Использование Symfony для мелкого API (можно посмотреть в сторону микро-фреймворков, например, тот же Silex) или простенького сайта можно сравнить с поездкой за продуктами на фуре-длинномере — да, едет, но медленнее и дороже в сравнении с легковыми. Второе исключение — использование Symfony «на вырост» в перспективе расширения проекта и его масштабируемости. В любом случае, инструмент следует выбирать исходя из задач, а не наоборот.

Symfony медленный

Я бы не назвал Symfony медленным. В рамках этой статьи мы не будем производить замеры производительности, у нас нет такой задачи, но думаю, не составит большого труда найти самые разнообразные бенчмарки php-фреймворков. Глядя на их результаты, становится ясно, что быстродействие Symfony на достойном уровне, хотя он и не является фаворитом в плане производительности, существуют более быстрые фреймворки. Важно понимать, почему так происходит. Все плюшки, которые мы получаем от работы с Symfony, требуют ресурсов, да и абстракция не бесплатна. За всё нужно платить, и в программировании за удобство, качество и скорость разработки зачастую приходится платить производительностью.

Здесь сразу возникает холиварный вопрос: что имеет бОльшую цену — стоимость разработки или стоимость хостинга? На мой взгляд, легче добавить сервер, тем самым повысив производительность приложения, чем найти и добавить нового разработчика на проект. Разумеется, это абсолютно не означает, что не нужно задумываться об оптимизации продукта и конечном быстродействии. Нужно, и очень важно всегда принимать во внимание данный аспект. Не открою Америки, если скажу, что оптимизация производительности не является лёгкой задачей. Для её решения следует понимать, что происходит внутри, и в деталях представлять, что может привести к замедлению и каким образом справляться с нагрузками.

Слишком много магии

Зачастую приходится слышать, что в Symfony очень много магии и не всегда понятно, что откуда получается и самое главное — как работает. Не могу полностью согласиться с этим. В Symfony магии не больше, чем в других фреймворках. Вообще использование любого фреймворка связано с некоторым уровнем «магии». И это нормально, одна из задач фреймворка — упрощать решение часто повторяющихся задач . Когда вы начинаете работать с фреймворком, вы используете примеры документации, готовые рецепты. При этом некоторые моменты могут быть не столь очевидны, могут быть непонятны, мы часто называем это магией. Вы используете магию фреймворка, и вроде бы всё хорошо. В определённый момент вы чувствуете недостаток стандартных возможностей фреймворка и рецептов, приходит время создать свою «магию». Создавая свою магию, вы разбираетесь в том, как на самом деле работает фреймворк, и в этот самый момент эта часть перестает для вас быть чёрным ящиком, и эта функциональность перестаёт для вас быть магией. Так происходит освоение фреймворка. Не нужно бояться того, что вы сразу не понимаете всех деталей.

Мощное сообщество

Пожалуй, этот аргумент можно услышать в разговоре о практически любом более-менее популярном фреймворке или языке программирования. Каждый убеждён, что сообщество масштабное, крайне дружелюбное, отзывчивое и готово причинять добро каждому новичку. Как бы это ни звучало банально, но сообщество Symfony на самом деле масштабное. Большое количество разработчиков на github и stackoverflow, которые отвечают на вопросы (в том числе core-разработчики и разработчики бандлов). При этом общение не является односторонним, любой желающий может создавать pull-request’ы, вносить предложения, создавать свои бандлы. Любителям живого общения следует отметить, что сообществом регулярно проводятся конференции как международные, так и национальные.

Поддержка и финансирование

Еще один важный момент для open-source проекта, который не всегда выделяют — поддержка коммерческой компании, в данном случае — SensioLabs. Компания предлагает дополнительные услуги, такие как консалтинг, обучение, различные сертификации. Это придает дополнительную уверенность в плане стабильности проекта, в дальнейшем росте и развитии экосистемы фреймворка.

Хорошая документация

Нельзя не отметить высокий уровень документации, она актуальна для каждой версии фреймворка, описывает не только компоненты, но и наиболее популярные бандлы. До недавнего времени на официальном сайте можно было найти книгу по практическому применению Symfony, список рецептов и лучшие практики по использованию фреймворка. К 5-летию второй версии фреймворка создатели решили основательно переработать документацию, создав два раздела: Getting started — короткая книга по основам работы с фреймворком и Guides — руководства по отдельным темам. К сожалению, все обозначенные выше материалы не доступны на русском языке, и этот факт можно отметить как дополнительный барьерчик для новичков, но не стоит пугаться — документация довольно хорошо структурирована, написана понятным и простым языком, содержит примеры кода и в ней достаточно легко разобраться.

Symfony не ограничивает вас в выборе, он предоставляет свободу действий, но в то же время требует детального понимания принципов работы и возлагает ответственность за построение структуры приложения.

Вся суть аннотаций Symfony в одном контроллере:

Getting started REST API with Symfony 4

The concept of the Internet of things is a trending topic and it has found implementation in numerous aspects. Computers, laptops, mobile phones, and other non-internet-enabled physical devices like cars, or smart grids can interact with each other. To do it they need a standardized interface called API (application programming interface). The advantage of using a unified interface is once you implement such a web service on your server, it can interact with a variety of client devices. In addition, it gives the ability to build a web application with separate back-end and front-end parts. You may use modern JS frameworks to make user interfaces more dynamic and achieve good UX. Many organizations integrate their mobile applications with back-end CRM, ERP, EAM, and other tools to improve their productivity.

We considered how to create API using the headless Drupal 8 approach in our previous articles, find them in the Useful links block. However, the functionality of a CMS may not have enough flexibility for the projects with complex business logic. In such cases, using a PHP framework may become a more preferable option.


Symfony is one of the most popular Open Source PHP frameworks consisting of separate components. They are used in many large projects, such as Drupal 8 or Laravel. Symfony has an active community and stable support. Also, it has the expandable architecture of reusable components called “bundle”, it extends the functionality of the framework. The latest Symfony version has a lot of improvements, such an automatic configuration of bundles with Symfony Flex and simplified folder structure increase the speed of development.

In this Symfony 4 tutorial, we will create a basic server back-end structure for your application using the REST API architecture style. We will use a ‘FOSRestBundle’ bundle as a basis, implement ‘get’ and ‘post’ methods to create and show the list of resources respectively. Besides that, we will add the OAuth2 authentication with FOSOAuthServerBundle.

Create a Rest API

Firstly, make sure you have installed PHP 7.1 or a higher version and the Composer package manager to create a new Symfony application. After that, create a new project by executing the following command in the terminal:

How to display the symfony profiler for API request made in the browser?

I’m developing a REST api with Symfony2 + FOSRest bundle.

I would like to know if there is any way for a call to the api in dev mode ( app_dev.php ) from the browser (corresponding to a Accept: text/html,application/xhtml+xml header) to display the response in the «specified format», wrapped in html with the profiler provided by symfony.

It would allow to debug calls to the api directly in the browser.

Edit: I don’t want to debug the HTTP request but the whole process (route matching, DB queries involved, etc). That’s why I want to have access to the symfony profiler.

5 Answers 5

Since Symfony 2.4, the profiler sets two additional settings in the HTTP header: X-Debug-Token and X-Debug-Token-Link . (see http://symfony.com/blog/new-in-symfony-2-4-quicker-access-to-the-profiler-when-working-on-an-api)

These headers contain the token and the direct link to the profiler for the current request. They are always sent if the profiler is enabled.

Not surprisingly, there is already an extension available for Chrome, that checks for the existence of these headers and provide extra information: Symfony2 Profiler shortcut

PHP Symfony 4 API Platform + React.js Full Stack мастер-класс

PHP Symfony 4 API Platform + React.js Full Stack Masterclass

Изучите Symfony PHP Framework, API Platform и React.js full stack — создайте полное приложение! Вы когда-нибудь хотели продвинуть свои навыки PHP на следующий уровень? Может быть, у вас есть опыт работы с PHP, но вы никогда не меняли работу с фреймворком? Или вы новичок в PHP вообще? Это не имеет значения! Вы можете пройти этот курс, чтобы дать вашим проектам PHP новый старт! В современном мире рано или поздно вам, как веб-разработчику, придется создавать API и приложение UI в React.JS или любой другой среде JS. Это просто необходимо в эти дни для любого профессионального веб-разработчика!

Здесь я могу вам помочь. Пройдите этот курс, чтобы узнать, как создавать надежные API в PHP, используя Symfony Framework 4 и API Platform. Вы не поверите, насколько это легко и быстро! Я проведу вас шаг за шагом в течение всего процесса, от создания собственного надежного API до создания современного приложения React.JS с использованием Redux, Redux-Form и всех других инструментов, которые вам просто необходимо знать, чтобы получить работу в эти дни. !

Вы будете создавать приложение «Блог», начиная с API в Symfony API Platform, а затем — полноценное приложение React + Redux. Мы также настроим панель администрирования для управления платформой.

Цукерберг рекомендует:  Адаптивное выпадающее меню на CSS3 и jQuery

Поддерживаются как Windows, так и MacOS (я покажу вам, как установить и настроить PHP и Node.js на обоих)

Что вы узнаете о Symfony и API Platform?

  • Вы узнаете, как создавать контроллеры Symfony и работать с маршрутизацией.
  • Вы узнаете, как представлять таблицы базы данных как объекты в Doctrine.
  • Вы увидите, как можно быстро преобразовать модель Doctrine в ресурс API
  • Вы узнаете, как разбивать на страницы, фильтровать и сортировать свои коллекции.
  • Вы увидите, как отправить электронное письмо
  • Вы узнаете все об Аутентификации (регистрация пользователя, вход, включая подтверждение учетной записи по электронной почте)
  • Вы поймете все об авторизации (роли пользователей, привилегии, ограничение доступа)
  • Вы узнаете, как обрабатывать загрузку файлов через REST API
  • Вы узнаете, как регистрировать ошибки
  • Вы изучите как модульное тестирование (PHPUnit), так и функциональное тестирование (Behat).
  • Вы узнаете, как настраивать и расширять встроенные операции, предоставляемые платформой API.
  • Проверка данных и сериализация / десериализация

Что вы узнаете о React.js?

  • Как настроить маршруты для вашего приложения с помощью React Router
  • Как обрабатывать состояние с Redux
  • Как создавать отличные формы с помощью Redux Forms
  • Связь с API с помощью Thunk Middleware

symfony2 Работа с API RESTFul

пример

REpresentational State Transfer (REST) ​​- это архитектурный стиль, используемый для веб-разработки, введенный и определенный в 2000 году Роем Филдингом.

Он основан на HTTP-протоколе ( HTTP на Wiki ), HTTP-запросах (GET, POST, PATCH, DELETE . ) / кодах ответов (404, 400, 200, 201, 500 . ) и структуре тел.

Это отличный способ разоблачить ваши данные в другой системе в Интернете.

Представьте, что вы хотите сделать RESTFul api для управления вашим StackOverFlower (User) в вашей локальной базе данных.

Давайте сделаем пример!


Концепция Symfony 2.8

  1. Веб сервер :

Вы должны установить и настроить веб-сервер на своей локальной машине, см. Wamp или Lamp или Mamp : у вас должна быть последняя версия PHP ( . Требования Symfony . )

Вы должны настроить PHP cli (в зависимости от нашей системы), введите это «PHP-cli [OS-NAME] how-to» в нашего друга Google! Вы должны установить композитор, см. « Установка композитора»

Вы должны установить Symfony 2.8 (с композитором, это лучший способ), открыть терминал (или cmd на окнах) и перейти на ваш веб-сервер.

Symfony 2 работает с одним из лучших типов структуры: Связки. Все — Связки на Symfony! Мы можем проверить это выше.

Перейдите к древовидной структуре и увидите: Symfony 2.8 установлен в каталоге «example».

  1. FOSRest (для FriendsOfSymfony) на JMSSerializer Bundle:

Вы должны установить эти два пакета:

Не забудьте активировать их в AppKernel.php!

Создайте свой собственный «пример» и создайте базу данных.

Перейдите в конец файла конфигурации приложения Symfony 2.8 и вставьте его:

Создайте свой каталог доктрины («example / src / ExampleBundle / Entity») и файл ресурсов («StackOverFlower.orm.yml»):

Создание схемы сущности и обновления:

Создайте контроллер по умолчанию:

Сделайте свой твиг по умолчанию:

Вы только что создали свой первый RESTFul API!

Как вы можете видеть в базе данных, новый пользователь был создан с именем «test».

У вас есть полный пример в моей учетной записи github этого примера: пример Git Hub , в ветке «master» в этом примере, а в ветке «real-routes» — пример с более подходящим URL (например, POST и DELETE).

How to build a Symfony 4 API Platform application from scratch

Published by nielsvandermolen on June 12, 2020 June 12, 2020

Symfony 4 and the API Platform Framework make it easy to create an API application with basic CRUD operations. However, in real-world applications more advanced features (e.g. authentication and custom endpoints) are needed which require quite a bit of knowledge to set-up. Therefore, in this blog article, we explore these advanced features by creating an example application that covers the following topics:

  • Step 1. Installation of API Platform and the EasyAdminBundle
  • Step 2. Creation of entities
  • Step 3. Making of demo content with DataFixtures
  • Step 4. Authentication with HTTP passwords
  • Step 5. Authentication with an API token
  • Step 6. Creation of custom API endpoints
  • Step 7. Functional smoke tests including security

I hope this article helps to reduce the time necessary to set up your own Symfony 4 API application. The example application is hosted on GitHub:

Each step in the blog article has a own commit in the repository. For readability sake, the full source code is not included in the article but we only highlight the important parts.

Step 1. Setting up the Symfony project

We use Docker to setup the application. Please read the related blog article for the reasons why to use Docker. Please look at commit 9c5b1e9 for the necessary files. Now, when we start the Docker containers with docker-compose up -d and go to the IP of the machine that is running Docker with port 8001 (in my case localhost:8001 ) you should see an error: «File not found» .

This is because we did not install Symfony. Let’s fix that issue by going into the Docker fpm (PHP) container and use Composer to install Symfony 4 in the project folder.

This results in a Symfony application with all the dependencies installed. For a detailed look on what is installed check the composer.json and composer.lock files.


Step 2. Let’s create some entities

The example application consists of an article entity with comments linked to it. Let’s create the Comment entity in the Docker container with Symfony Maker:

Next, we create the Article entity and create the relationship to the Comment entity:

This should give you the two entities in project/src/Entity/ :

Since we want to use these ids in other applications we do want to change the id fields of the entities to use the Doctrine UUID instead of the default auto incremental ID.

Furthermore, in order to use the admin interface we want to implement the __toString methods for both entities:

Now, it is time to add some configuration. First, we have to change the DATABASE_URL environment variable in the project/.env file to mysql://root:root@db:3306/project_db . Then we want to change the project/config/packages/easy_admin.yaml file to include our new entities:

Finally, it is time to create the database:

Now, we should have a fully functional admin interface on localhost:8001/admin and a working CRUD API for the entities with documentation on localhost:8001/api

Step 3. Doctrine data fixtures

To speed up development and have some content for our automated tests it is a good practice to write a DataFixture. First, create an initial > ./bin/console make:fixtures and call it AppFixtures. In project/src/DataFixtures/AppFixtures.php we can create some articles with comments on them:

// /project/src/DataFixtures/AppFixtures.php
class AppFixtures extends Fixture
<
public function load ( ObjectManager $manager )
<
for ( $i = 0 ; $i 10 ; $i ++ ) <
$article = new Article ( ) ;
$article -> setBody ( ‘This is a body of article ‘ . $i ) ;

for ( $i2 = 0 ; $i2 $i ; $i2 ++ ) <
$comment = new Comment ( ) ;
$comment -> setBody ( ‘This is the body of comment ‘ . $i2 . ‘ of article ‘ . $i ) ;
$comment -> setArticle ( $article ) ;
$manager -> persist ( $comment ) ;
>
$manager -> persist ( $article ) ;
>

The content in the Datafixture will replace the content in the current database when calling: ./bin/console doctrine:fixtures:load -n

Step 4. Making the application secure – HTTP password

Currently, there is no security applied in the Symfony application and anyone that can access the server can create and delete entities. The easiest method to make the application secure is to add an HTTP password by creating an in_memory user prov > projects/config/packages/security.yaml :

The encrypted passwords can be generated with ./bin/console security:encode-password . Now, the application should be behind an HTTP password in this case: admin/admin .

Step 5. Making the application secure – Token authentication

However, we do not want to have to use an HTTP password to make a request to an API. Therefore, we want to use an authentication token that gets sent in with every request. In the example application, we follow the tutorial by Symfony where they use the Symfony Guard authentication system. The full commit for the implementation of the token authentication step is 46866ac.

The security.yaml file has these changed added:

A new User entity has to be created with make:entity which we do not expose with the API but we do want to add it to the easy_admin.yaml file and to the DataFixture. Furthermore, after creating the fixture for the entity you have to update the database again with doctrine:fixtures:load -n

// project/src/Entity/User.
/**
* @ORM\Table(name=»app_users»)
* @ORM\Entity(repository )
*/
class User implements UserInterface , \Serializable
<
/**
* @ORM\Id
* @ORM\Column(type=»gu > * @ORM\GeneratedValue(strategy=»UUID»)
*/
private $id ;

/**
* @ORM\Column(type=»string», length=64, unique=true))
*/
private $apiKey ;

/**
* @ORM\Column(type=»string», length=25)
*/
private $username ;

/**
* @ORM\Column(type=»string», length=64)
*/
private $password ;

public function getRoles ( )
<
return array ( ‘ROLE_API’ ) ;
>

public function eraseCredentials ( )
<
>
// .. Other getters and setters
>

Another useful step is to add this Swagger configuration so we can use the token authentication in the API documentation. You do have to remove the role_hierarchy of the admin role or change the security configuration in order to test it with the documentation. However, it does already improve the documentation by adding the header correctly to the curl commands.

You can test the authentication by using curl on an endpoint and setting the token in the request header:

Step 6. Custom API endpoints

API Platform uses the concept of operations for creating API endpoints and there are various methods for defining custom operations. The native Symfony controller method seems to work most intuitively so that is the one that we use. First, let’s create a new service that counts the number of comments on an article:

// project/src/Service/ArticleService.php
use App\Entity\Article ;


class ArticleService <
public function countCommentsinArticle ( Article $article ) <
$count = $article -> getComments ( ) -> count ( ) ;
return $count ;
>
>

Now, we want to create a Symfony controller with make:controller and create a method that calls the service and maps it to the API operation:

The last step is to make the operations explicit on the Article entity annotations and add the Swagger documentation:

That’s it! Now the custom API endpoint should show up on the API documentation page ( localhost:8001/api ) and you should be able to use the endpoint by using the UUID of an article e.g.:

Step 7. Automated testing

It is always a good idea to write some smoke test for your PHP application because they are very easy to write and they provide feedback if your application is still “compiling” and that it is secure.

First, we add a new security HTTP password for the test environment:

Then we can add our tests:

// project/tests/SmokeFunctionalTest.php
use Symfony\Bundle\FrameworkBundle\Test\WebTestCase ;

class SmokeFunctionalTest extends WebTestCase <

/**
* @dataProvider urlProvider
*/
public function testPageIsSecure ( $url ) <
$client = self :: createClient ( [ ] , [
‘PHP_AUTH_USER’ => ‘test’ ,
‘PHP_AUTH_PW’ => ‘incorrect_pw’ ,
] ) ;
$client -> request ( ‘GET’ , $url ) ;
$this -> assertFalse ( $client -> getResponse ( ) -> isSuccessful ( ) ) ;
>

/**
* @dataProvider urlProvider
*/
public function testPageIsSuccessful ( $url ) <
$client = self :: createClient ( [ ] , [
‘PHP_AUTH_USER’ => ‘test’ ,
‘PHP_AUTH_PW’ => ‘test’ ,
] ) ;
$client -> request ( ‘GET’ , $url ) ;
$this -> assertTrue ( $client -> getResponse ( ) -> isSuccessful ( ) ) ;
>

public function urlProv >( ) <
yield [ ‘/api’ ] ;
yield [ ‘/admin/?entity=Article’ ] ;
yield [ ‘/admin/?entity=Comment’ ] ;
yield [ ‘/admin/?entity=User’ ] ;
>

/**
* @dataProvider urlApiProvider
*/
public function testAPIisSecure ( $url ) <
$client = self :: createClient ( [ ] ) ;
$client -> request ( ‘GET’ , $url , [ ] , [ ] , [ ‘HTTP_X_AUTH_TOKEN’ => ‘incorrect_api_key’ , ‘HTTP_ACCEPT’ => ‘application/json’ ] ) ;
$this -> assertFalse ( $client -> getResponse ( ) -> isSuccessful ( ) ) ;
>

/**
* @dataProvider urlApiProvider
*/
public function testAPIWorks ( $url ) <
$client = self :: createClient ( [ ] ) ;
$client -> request ( ‘GET’ , $url , [ ] , [ ] , [ ‘HTTP_X_AUTH_TOKEN’ => ‘test_api_key’ , ‘HTTP_ACCEPT’ => ‘application/json’ ] ) ;
$this -> assertTrue ( $client -> getResponse ( ) -> isSuccessful ( ) ) ;
>

public function urlApiProv >( ) <
yield [ ‘/api/articles’ ] ;
yield [ ‘/api/comments’ ] ;
>
>

Before we can run the tests we need to add some environment variables to the phpunit.xml.dist file:

>
.
name = «CORS_ALLOW_ORIGIN» value = «^http://localhost:?[0-9]*$» />
name = «DATABASE_URL» value = «mysql://root:root@db:3306/environments» />
.

There we go, we can now execute the PHPUnit tests in the Docker container with:

Discussion

Congratulations for making it to the end of the article as it had a high density of concepts which were not explained in a detailed matter. For some topics, it is most educative to see a collection of opinionated code that works. We have just touched the basics on what is possible with Symfony and the API Platform Framework we hope this will give you a headstart in developing your API application. I am in the middle of learning to develop with these technologies as well so please let me know if you think there are better ways to do things and why.

Цукерберг рекомендует:  Web программирование - ищу друзей по web программированию

If you learned something from this article please consider leaving a comment, sharing it with your peers or to

20 Comments

nielsvandermolen · June 21, 2020 at 10:39 am

There is a small mistake in Step 6. Custom API endpoints. It is better when the route path starts with api/ for the authentication to work for the custom operations. Updated the article and the repository to resolve this issue.

Mahdy Nasr · December 5, 2020 at 7:05 pm

very amazing tutorial, very descriptive and helpful, many thanks ��������

nielsvandermolen · December 7, 2020 at 6:11 pm

Vladimir · December 8, 2020 at 2:57 pm

Why we need ArticleService? We can not write this in the controller?:
$data->getComments()->count()

nielsvandermolen · December 10, 2020 at 8:25 am


Yes, you could. The service endpoint is basically a placeholder for your own (more complex) endpoints. When you use multiple entries like an Admin interface and an API it is still valuable in maintenance to put this code in the service instead of repeating it multiple times.

It provides cleaner code when you put all your business logic in services and not in controllers or other places.

naoufal · January 9, 2020 at 2:00 pm

this is very good tutorial thank you!

Dave · January 17, 2020 at 2:56 pm

Where’ve you been all of my life? ��

Anonymous · January 24, 2020 at 8:11 pm

Thanks a lot. This has made my life a lot easier. Very rich information in a short tutorial

Sean · January 24, 2020 at 8:12 pm

Great work. Very helpful indeed!

nielsvandermolen · January 25, 2020 at 10:10 am

Thanks for the comments, I am glad the tutorial is helpful for this many people.

Anon · March 6, 2020 at 5:44 pm

The php docker file no longer builds:
[Error]
checking for libzip… not found
configure: error: Please reinstall the libzip distribution
ERROR: Service ‘fpm’ failed to build: The command ‘/bin/sh -c apt-get update && apt-get install -y –no-install-recommends git zlib1g-dev libxml2-
dev && docker-php-ext-install pdo_mysql zip’ returned a non-zero code: 1
SlyMachine:symf dev$ docker-compose up -d
Building fpm
Step 1/4 : FROM php:fpm
—> 9343626a0f09
Step 2/4 : RUN apt-get update && apt-get install -y –no-install-recommends git zlib1g-dev libxml2-dev RUN curl -sS https://getcomposer.org/instal
ler | php && mv composer.phar /usr/local/bin/composer
—> Running in 6b6e0d64ebe6
Get:1 http://security-cdn.debian.org/debian-security stretch/updates InRelease [94.3 kB]
Ign:2 http://cdn-fastly.deb.debian.org/debian stretch InRelease
Get:4 http://cdn-fastly.deb.debian.org/debian stretch-updates InRelease [91.0 kB]
Get:3 http://security-cdn.debian.org/debian-security buster/updates InRelease [38.3 kB]
Get:8 http://security-cdn.debian.org/debian-security stretch/updates/main amd64 Packages [476 kB]
Get:5 http://cdn-fastly.deb.debian.org/debian buster InRelease [158 kB]
Get:6 http://cdn-fastly.deb.debian.org/debian buster-updates InRelease [46.8 kB]
Get:7 http://cdn-fastly.deb.debian.org/debian stretch Release [118 kB]
Get:9 http://cdn-fastly.deb.debian.org/debian stretch-updates/main amd64 Packages [11.1 kB]
Get:10 http://cdn-fastly.deb.debian.org/debian buster/main amd64 Packages [7966 kB]
Get:11 http://cdn-fastly.deb.debian.org/debian stretch Release.gpg [2434 B]
Get:12 http://cdn-fastly.deb.debian.org/debian stretch/main amd64 Packages [7084 kB]
Fetched 16.1 MB in 8s (1857 kB/s)
Reading package lists…
E: Command line option ‘S’ [from -sS] is not understood in combination with the other options.
mv: cannot stat ‘composer.phar’: No such file or directory
ERROR: Service ‘fpm’ failed to build: The command ‘/bin/sh -c apt-get update && apt-get install -y –no-install-recommends git zlib1g-dev libxml2-
dev RUN curl -sS https://getcomposer.org/installer | php && mv composer.phar /usr/local/bin/composer’ returned a non-zero code: 1

nielsvandermolen · March 7, 2020 at 8:54 pm

You can try to add the libzip-dev package.

Why hide text · May 18, 2020 at 11:46 am

The tutorial is interesting and good, but you should think a few hours about tthe meaning of CONTRAST – it is a very usable thing and it helps to make things readable. There are some important parts in this tutorial that are NOT easily readable because there is nearly no CONTRAST – grey text on black background is a good example of how to punish your readers. Please take a look at https://www.contrastrebellion.com/ to lern some basic things about how important contrast is to make text readable.

No this is not about personal taste – text also has a function, and all creative things should respect that functions. Good, well educated desigenrs understand that, and using good contrast is a good tool to recognize the quality of a designer.

BTW also the text on your main blog page suffers from a lack of contrast.

nielsvandermolen · May 18, 2020 at 7:39 pm

Thanks for the feedback, the contrast of the code should now be better. Also increased the font size!

Olga · May 19, 2020 at 11:24 pm

Yes, the Tutorial is fine, but by using docker we inherit a few problems that would not exist without it.

First, the PostgreSQL DB in the docker setup of openapi-platform did not contain the uuid-ossp extension, which seems to be needed, so we have to manually install that otherwise the uuid will not be generated by fixtures.

Also trying to generate the fixtures we get this fantastic error:
cURL error 6: Could not resolve host: cache-proxy

this is a nice example how docker complicates a setup very quickly – now you have to dive deep into why that cache-proxy is not found in the docker network. Fun! Yes, of course we will find a fix, but we wanted to do something else than fixing docker setups…

Leonardo Cuquejo · June 1, 2020 at 1:11 pm

Great Tutorial, Now I have JWT working in my system!

Just one question. If I have the token all works fine, but I didn’t find a route to get the token from a user/pass.

You know, like my frontend should have a login page, after submitting the user and pass will receive the token for this user.

nielsvandermolen · June 2, 2020 at 7:54 pm

Thanks, there is a feature for that in Symfony by using json_login.


I recommend you subscribe to this API Platform (paid) course in which Ryan and I describe this with an example (it will likely be around 18. which will be released soonish).
https://symfonycasts.com/screencast/api-platform

sam tion · June 17, 2020 at 5:10 pm

In the time it took you to explain the reasons to use docker and how to configure it to get started before even getting into symfony, I can have a LAMP stack up and running on a VPS from a premade image. Just saying. Docker is a tool but it is not always the best way to go for everyone. That is probably why symfony doesn’t even mention it.

Mohamad Yusuf Ibrahim · August 28, 2020 at 5:58 am

wow, looks so great… will try this tutorial this night

Api — Symfony. Организация файлов для API.

SymfonyApi сборка для создания REST API с авторской конфигурацией.

Создание приложения с помощью Composer

Указываем переменные окружения для приложения.

Запускаем команду для создания базы.

В приложении по умолчанию реализована авторизация пользователя с помощью JWT. Документация по бандлу реализующему JWT здесь. Для создания пользователя можете использовать любой REST client, отправив post запрос на http://my-project/api/register с данными:

или используя curl

После подтверждения email, получаем токен отправляя запрос http://my-project/api/token :

или используя curl

SymfonyApi вернет 2 текстовых поля:

Для авторизации в приложении отправляем заголовок: Authorization: Bearer your_token.

REST API в SymfonyApi реализовано с помощью бандла api-platform. Подробную документацию по использованию данного бандла можно посмотреть здесь. В частности часто встречающиеся задачи:

  • Настройка авторизации
  • Нормализация/Денормализация
  • Получения разных проекций (набора возвращаемых полей)
  • Создание слушателей, событий, помощников и обработчиков

SymfonyApi включает в себя следующие особенности:

  • Контроллер авторизации, регистрации
  • Предоставляет мультиязычность
  • Интегрирован с проектом media-server

Пользователь и авторизация

Для организации пользователей на сайте не используется FOSUserBundle. Портирована лишь самая необходимая часть связанная с авторизацией, и пропущены все части, связанные с событиями, личными кабинетами, и прочей ненужной информацией.

Если необходимо использовать FOSUserBundle, можно удалить все файлы связанные с пользователем, и подключить FOSUserBundle и не забыть сконфигурировать security.yaml.

Для авторизации используется модель JWT, используемая в api-platform.

Gedmo Translatable реализует мультиязычностьв проекте. Для того, чтобы api-platform возвращала translations — поле c переводами, необходимо, чтобы класс сущности имплементировал интерфейс Gedmo\Translatable\Translatable. Поле перевода будет иметь вид:

Аналогично, для того, чтобы обработать и сохранить переводы, достаточно при запросе добавить параметр translations .

Стоит отметить, что Gedmo Translatable, не дублирует данные переводов. Если по-умолчанию в приложении установлен английский язык, то в translations английского языка не будет (будет установлен в значении полей)

Это можно исправить, заставив явно дублировать данные в App\Handler\TranslationHandler в SymfonyApi.

  • api-platform/core
  • doctrine/annotations
  • gedmo/doctrine-extensions
  • gesdinet/jwt-refresh-token-bundle
  • gfreeau/get-jwt-bundle
  • guzzlehttp/guzzle
  • lexik/jwt-authentication-bundle
  • nelmio/cors-bundle
  • symfony/asset
  • symfony/console
  • symfony/expression-language
  • symfony/flex
  • symfony/framework-bundle
  • symfony/lts
  • symfony/maker-bundle,
  • symfony/orm-pack
  • symfony/swiftmailer-bundle
  • symfony/twig-bundleч
  • symfony/val >

Api — Symfony. Организация файлов для API.


Группа: Главные администраторы
Сообщений: 14349
Регистрация: 12.10.2007
Из: Twilight Zone
Пользователь №: 1

Symfony*,
PHP*,
API*
Так вышло, что всю свою не долгую карьеру я занимаюсь разработкой API для мобильных приложений и сайтов на Symfony2. Каждый раз открываю для себя все новые знания, которые кому-то покажутся очевидными, а кому-то помогут сэкономить не мало времени. Об этих знаниях и пойдет речь.

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

Первая проблема возникает с entity type. Когда вы отсылаете запрос к методу, который использует entity type в формах – сначала достаются все сущности указанного класса, и только потом запрос на получение нужной сущности по отправленному id. Многие не знают об этом и очень удивляются, почему метод работает так долго.

public function setDefaultOptions(OptionsResolverInterface $resolver)
<
$resolver->setDefaults([
‘field’ => ‘id’,
‘class’ => null,
‘compound’ => false
]);

public function buildForm(FormBuilderInterface $builder, array $options)
<
$builder->addModelTransformer(new EntityDataTransformer($this->em, $options[‘class’], $options[‘field’]));
>

public function getName()
<
return ‘entity’;
>
>

em = $em;
$this->entityName = $entityName;
$this->fieldName = $fieldName;
>

public function transform($value)
<
return null;
>

public function reverseTransform($value)
<
if (!$value) <
return null;
>

return $this->em->getRepository($this->entityName)->findOneBy([$this->fieldName => $value]);
>
>

common.form.type.entity:
class: AppCommonBundleFormTypeEntityType
arguments: [@doctrine.orm.entity_manager]
tags:

Вторая проблема возникает с checkbox type, который пытаются использовать для булевых значений, но особенность работы этого типа такова, что если ключ существует и он не пустой, то вернется true.

public function getParent()
<
return ‘text’;
>

public function getName()
<
return ‘boolean’;
>
>

use SymfonyComponentFormDataTransformerInterface;
use SymfonyComponentFormExceptionTransformationFailedException;

class BooleanDataTransformer implements DataTransformerInterface
<
public function transform($value)
<
return null;
>

public function reverseTransform($value)
<
if ($value === «false» || $value === «0» || $value === «» || $value === 0) <
return false;
>

common.form.type.boolean:
class: AppCommonBundleFormTypeBooleanType
tags:

Во всех статьях про создание API советуется именно это замечательное расширение. Люди смотрят простенький пример, где у сущностей есть две serialization groups: details и list, и начинают у каждой сущности использовать именно эти названия и все замечательно работает, пока не попадется какая-нибудь связанная сущность, у которой группы названы точно так же и выводится очень много лишней, не нужной информации. Так же это может уводить в бесконечный цикл при сериализации, если обе модели выводят связь друг с другом.

Пример неправильного использованияNews.php

use JMSSerializerAnnotation as Serialization;

/**
* Связь с сущностью User
*
* @SerializationGroups(<"details", "list">)
*/
protected $author;
>

use JMSSerializerAnnotation as Serialization;

/** Огромный список полей отмеченных группами list и details */
>

class NewsController extends BaseController
<
/**
* @SerializationGroups(<"details">)
* @Route(«/news/< >)
*/
public function detailsAction(CommonEntityNews $entity)
<
return $entity;
>
>

В примере видно, что при получении новости в поле author будут все поля, которые в User с группой details, что явно не входит в наши планы. Казалось бы очевидно, что так делать нельзя, но к моему удивлению так делают многие.

Я советую именовать группы как %entity_name%_details, %entity_name%_list и %entity_name%_embed. Последняя нужна как раз для тех случаев, когда есть связанные сущности и мы хотим вывести какую-то связанную сущность в списке.

Пример правильного использованияNews.php

use JMSSerializerAnnotation as Serialization;

use JMSSerializerAnnotation as Serialization;

/** Огромный список полей, которые отмечены группами user_list и user_details */
>

class NewsController extends BaseController
<
/**
* @SerializationGroups(<"news_details", "user_embed">)
* @Route(«/news/< >)
*/
public function detailsAction(CommonEntityNews $entity)
<
return $entity;
>
>

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

На самом деле, подобных советов еще очень много и если вам будет интересно, я с радостью ими поделюсь.

Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих