REST API за пару минут с Lionframe

[@voidnugget]

Когда существуюет 100+ табличек БД — 100+ различных контролллеров с 10-20 сервисами и сложной бизнесс-логикой, поддерживать генерируемый код очень сложно и без хорошего покрытия тестами это приводит к различным побочным эффектам. Это anti-DDD проектирование.

Гораздо проще загрузить схему БД и создать контроллер в с маршрутами

GET /{entityname}/{id}
GET /plural({entityname})
POST /new/{entityname}/
PUT /edit/{entityname}/{id}
DELETE /remove/{entityname}/{id}
OPTIONS /{entityname}/schema
OPTIONS /{entityname}/caching
OPTIONS /{entityname}/rights

OPTIONS /{entityname}/{id}/subscribe
OPTIONS /{entityname}/{id}/changed

C него можно реализовать полноценный RESTful сервис, который будет загружать правила авторизации (c Authorization сервиса) по принципу «запрещено всё, что не разрешено явно», и даст возможность загружать схему данных (типа JSON-Schema) в форнтенд для автоматизческой генерации основных правил валидации, предоставит интерфейсы для реализации сервиса учёта (Accounting) и аутентификации (Authentication).

OPTIONS методы subscribe и changed используются для оповещения об изменениях (JSON-patch, можно и по comet'у, можно и по вэбсокетах) и блокировке сущностей.

Это SOA по DDD, без генерации тонны копи-пасты.

[@voidnugget]

Забыл добавить что для many-to-many связей и one-to-many можно добавить обработку batch запросов в виде

POST /add/plural({entityname})/[to|for]/{entityname}/id
DELETE /remove/plural({entityname})/from/{entityname}/id

p.s. Это тема для отдельной статьи, которую мне уже не хочется писать после комментариев к предыдущей.

[@hospect]

Жаль, что не хочется. Было бы интересно почитать.

[@VolCh]

К опросу: Нужно понимать, что генераторы генераторам рознь. Одни генерируют «заглушки» и «скелеты», подразумевая, что основной код будет писаться руками, другие генерируют работоспособный код для типовых задач, подразумевая его расширение для нетиповых, третьи же «думают», что всё предусмотрели и правки кода пользователем вообще не требуются (утрирую, но не сильно).

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

[@hospect]

По поводу опроса — здесь речь шла о тех, которые генерируют работоспособный код для типовых задач, как описанный здесь Lionframe.

[@voidnugget]

Есть понятие Scaffolding'a — это процесс который генерирует для всех табличек в базе по контроллеру, шаблону и тесту для MVC приложения.
Понятное дело что это всё нужно будет потом переписывать под себя, в том числе и часть шаблонов генератора. Как показывает моя практика, scaffolding в lionframe, или Grails, допилить достаточно просто.

В этом комментарии описываются абстрактные генераторы в вакууме — напишите конкретно о решениях которые имеются ввиду, иначе это просто ваше субъективное суждение не обоснованное практикой.

[@hanovruslan]

Основая причина появления этого продукта, мне думается, не очередная стопицотая проверка полезности генератора рутинного (!) кода. Скорее тут речь об инкапсуляции контроллеров внутри бандла. (SyliusResourceBundle). Разработчику же передается панель с ручками (symfony приложение с его богатым инструментарием) и модельные классы ( Doctrine ORM, Doctrine ODM и прочая ) для связи БД.

[@hospect]

очередная стопицотая проверка полезности генератора рутинного (!) кода

Это исключительно инициатива автора этой статьи.

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

[@hospect]

Буквально вчера наткнулся на еще одну тулзу для генерации REST API — Microrest. В этот раз на основе Silex и Doctrine. Почитать о нем можно здесь.