Выбор фреймворка для создания REST-сервисов

Question

[afiskon]

Часть вопроса, которую читать необязательно:

Кому доводилось работать над REST-сервисами, знает, что это довольно скучное занятие. Ты создаешь ресурс, говоришь что в него можно ходить такими-то и такими-то методами, записи имеют определенный набор полей с ограничениями на их значения, а также значения по умолчанию. Хранится это часто в обычной РСУБД. Ну плюс к этому есть несколько представлений, например, json и csv, пара несложных фичей типа фильтрации по значению-диапазону, указания полей, которые нужно отдать при чтении, возможно также подписака на обновления, автоматическая миграция схемы БД и возможность создавать вьюхи по хитрым бизнес-правилам.

Сама суть вопроса:

Насколько я могу судить, в мире Java есть множество фреймворков, позволяющие получить все названное выше, а также автоматическую генерацию документации и клиентов к REST-сервису на десяти ЯП, путем простого описания ресурсов на неком DSL. Какой фреймворк вы бы порекомендовали? Что вы или кто-то из ваших коллег может сказать о нем по своему опыту использования?

Answer 1

[Сергей Протько]

Symfony имеет все нужные инструменты (Fos/rest-bundle, jms/serializer-bundle, аннотации, кучи плюшек).

Последний год пишу REST-Api на Silex+Doctrine. Все собственно то же самое что и в Symfony, только чуть проще структура выходит. Ну и да, нужно потратить день-два на настройку темплейта для проекта (что бы можно было использовать все теже аннтоации, jms-serializer, всякие хэлперы, генератор документации и т.д.). А уже этот темплейт можно реюзать.

Более того, можно еще больше минимизировать рутину, если использовать десериализацию данных запроса, но там есть нюансы.

Так же для внедрения всяких полезностей вроде CORS или OAuth можно использовать мидлвары (Поддерживает все фреймворки реализующие HttpkernelInterface, то есть Symfony, Silex, Laravel и т.д. Ну и можно прилепить к любому фреймворку декоратор).

Answer 2

[Юрий Ярош]

Не знаю о каком-таком "множестве фреймворков" идёт речь.
Сейчас кроме swagger-codegen'a нормальных кодогенераторов замечено не было, оно дружит со Scalatra и play2. В принципе можно написать любой шаблон для кодогенерации под что душе угодно, и не такое уж это и муторное занятие как принято думать.

Генерация Swagger спеки, вместе с endpoint'aми по схеме БД пока только в планах у typesafe, также они хотели написать автоматическую REST-мапилку с шаблонными контроллерами, аля tastypie под Scala. Ещё с этой же серии есть django-rest-framework и это всё барахло неоднократно переписывалось под Node.js. Под PHP подобных вундервафей замечено не было - там тоже принято "кодогенерировать" по схемам БД, и там тоже были плюшки для генерации спек Swagger'a.

Я вот планирую написать что-то похожее под Vert.x.

Comments

[Сергей Протько]

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

[Сергей Протько]

ии разве сваггер-кодоген это не для клиента?

[Юрий Ярош]

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

По поводу endpoint'ов как раз таки лучше генерить обрабатывать запросы через 6-7 шаблонных контроллеров с возможностью переопределения различных обработчиков типа beforeValidation(Model, List, AsyncResultHandler) etc, и документацию хранить в предварительно сгенерянных файликах под apidoc / swagger, либо сразу в базе со специальным endpoint'ом и отдельной схемой.

В общем нужно делать так что бы был 1 CRUD контроллер на много табличек БД, с возможностью переопределения частных случаев для каждой сущности. Материализованные и промежуточные представления вместе с различными функциями агрегации и их индексами - отдельная тема.

[Сергей Протько]

Юрий Ярош: я делаю генератор на основе api blueprint, с генерацией под каждый ресурс своего контроллера + DTO-шки. Не один CRUD контроллер на много сущностей, а вообще изолировать интерфейс приложения от его реализации. Руками это все писать весьма утомительно....

[Юрий Ярош]

Сергей Протько: в общем я имел ввиду то как это сделано в tastypie и django-rest-framework.

[Сергей Протько]

Юрий Ярош: не превествую подход django-rest-framework и завязывания API на ORM. Если я конечно правильно уловил суть.