Подтвердить что ты не робот

Современная веб-среда Java для приложений GUI RESTful?

Да, я знаю, старый вопрос о лучшем веб-фреймворке... но позвольте мне объяснить.

Я ищу веб-фреймворк на базе Java Servlet, который допускает взаимодействие RESTful, а также подходит для создания веб-графических интерфейсов.

Что я хочу:

  • Поддержка REST с согласованием содержимого HTTP и хорошим отображением URL-адресов.
  • преобразование данных из параметров запроса в объект домена (и в идеале другое направление)
  • не нужно дублировать объект домена как интерфейс к сети (например, в расположении)
  • простая интеграция EJB
  • Включение зависимостей должно выполняться сервером Java EE
  • понятный код (мне не нравится Spring MVCs магия wirering компонентов в пути класса)
  • легко настроить (то, что не настроено в Spring магически утомительно для настройки в контейнере - я бы предпочел иногда прямые зависимости)
  • колесо не должно быть повторно выбрано, например. г. что-то вроде JPA и BeanValidation должно быть использовано и не заново изобретено каркасом, или, по крайней мере, эти стандарты должны быть просты в использовании.
  • Поддержка валидации с отображением ошибок в формах
  • поддержка интернационализации

Кандидаты:

  • Spring MVC является мощным, но я устал от конфигурации Spring и не люблю модель программирования. Я думаю, что это слишком абстрактно и гибко и, следовательно, требует большой конфигурации. И мне не нравится способ Spring MVC использует аннотации. Но есть и некоторые недостатки дизайна, такие как методы, возвращающие значение через return и через выходной параметр - действительно уродливый! Я думаю, что было бы нелегко использовать Spring MVC с инъекцией зависимости Java EE, так как Spring MVC сильно полагается на Spring DI.

  • Roo кажется классным, но это просто еще один способ создать приложение Spring MVC, и он делает некоторые странные вещи с AOP.

  • Struts несколько неудобно и устарело.

  • Stripes Подход ActionBean выглядит не намного лучше, чем Struts. Мне это не нравится.

  • Grails приятный, но глючный (по крайней мере до 1.2). Reeinvents колесо: Я бы предпочел JPA над Gorm, например.

См. также 10 лучших веб-фреймворков Java

Я не ищу фреймворки с состоянием пользовательского интерфейса на сервере, например, Wicket, Tapestry или JSF. Я думаю, что этот подход противоречит фундаментальным принципам Интернета!

Так что делать? Создать структуру с нуля? хм...

Я хотел бы иметь что-то вроде JAX-RS с поддержкой классических графических интерфейсов браузера. Например, структура должна поддерживать проверку и помещать ошибку проверки в повторно отображаемую форму. Есть что-то в этом роде? Любые рекомендации?

4b9b3361

Ответ 1

Я думаю, что ваша характеристика Grails как "багги" немного сурова. Хотя вы сталкиваетесь с ошибками при использовании Grails, это часто основополагающие рамки (Spring, Hibernate) или плагин, ответственный, а не Grails.

Кроме того, учитывая, что Hibernate является реализацией JPA, действительно ли имеет смысл сказать, что

Я бы предпочел JPA над Gorm

В любом случае, если вы действительно недовольны Grails или любой другой структурой, о которой вы упоминали, Play framework может быть стоит посмотреть.

Ответ 2

Я рассказывал об использовании JAX-RS в качестве объединяющей веб-структуры в прошлом. Вы можете сделать все, что вам нужно, с помощью JAX-RS; основной недостаток - все части, возможно, не так хорошо документированы в одном месте, как с такими вещами, как Spring MVC, Stripes, Grails, Seam и др.

Для просмотров его довольно простой в использовании JAX-RS с Jersey и поддержка веб-интерфейсов в HTML в дополнение к службам RESTful в JSON/XML/независимо. Вы можете повторно использовать согласованное согласование JAXRS, так что заголовки заголовков HTTP-содержимого используются для определения того, возвращается ли HTML или XML и т.д. (Плюс вы можете загрузить HTML на стороне сервера, чтобы избежать использования XML для некоторых веб-браузеров, которые предоставляют нечетные принимающие заголовки - я глядя на вас Safari, который предпочитает XML для HTML!). например добавление @ImplicitProduces ( "text/html; qs = 5" ) к вашему ресурсу bean будет весить HTML выше любого другого представления. Вы также можете настроить постинфиксы URI (например, добавление .html или .xml или .json), чтобы переопределить согласование содержимого; что значительно упрощает тестирование различных представлений в браузере.

Джерси поддерживает неявные представления, поэтому вы можете визуализировать представления в HTML с помощью любого механизма шаблонов, например JSP или Поднимите шаблоны или что угодно; затем используйте более традиционные поставщики JAX-RS для сортировки типов XML/JSON. Вы можете быть явным с представлениями; или пусть JAX-RS найдет ваш шаблон и т.д.

Чтобы увидеть неявные взгляды в действии, вероятно, стоит загрузить источник для Джерси и посмотреть на образцы, например книжный магазин (поиск по @ImplicitProduces, если вам нравится).

С точки зрения проверки, его легко интегрировать Bean Validation JSR в ресурс bean; поэтому вы можете выполнить выборочную проверку ресурса или DTO или что-то еще. Точно так же хорошая поддержка размещения в Джерси (форма beans).

Я бы рекомендовал использовать некоторую инфраструктуру DI/IoC для вставки ресурса beans в нужные им вещи (например, материал базы данных, bean материал проверки или служебные объекты или еще что-то еще). Guice очень хорошо работает с Джерси, если вы хотите избежать Spring; хотя Spring с JavaConfig действительно избегает большого количества XML.

Для сложных пользовательских интерфейсов вы, вероятно, захотите использовать JavaScript на клиенте в эти дни. В то время как с JavaScript легко ссылаться на службы обслуживания (особенно если они используют JSON или JSONP) - недостающая часть элегантно повторно использует сервисы RESTful в Java/JAX-RS от GWT. Пока RestyGWT выглядит наиболее перспективным. В один прекрасный день, возможно, лучшая структура маршаллинга JSON, Jackson будет иметь собственные привязки GWT. Идея заключалась бы в повторном использовании объектов DTO в GWT на стороне клиента и на стороне сервера JAX-RS, оставаясь полностью RESTful.

Ответ 3

Я хотел бы упомянуть Restlet Framework, которая была первой базой REST для Java, когда она была запущена в 2005 году. Она зрелая, масштабируемый, имеет большую базу пользователей и активное сообщество.

Версия 2.0 находится в стадии окончательной разработки и предоставляет широкий набор функций, включая:

  • полное отображение понятий HTTP в чистом Java API
  • совместимый API для клиентской и серверной сторон
  • интеграция со многими популярными технологиями (FreeMarker, Velocity, Spring, Jackson, XStream, JAXB, Atom, OData/WCF Data Services и т.д.).
  • может быть развернут в автономном Java SE, внутри контейнера Java EE/Servlet, в Google App Engine, Android и даже в GWT, для которого он знает, как автоматически сериализовать beans с использованием отложенной привязки (аналогично GWT-RPC, но RESTful)
  • предоставляет множество соединителей для HTTP, SMTP, POP, JDBC, SIP и т.д.
  • полный пакет безопасности, встроенный, ориентированный на веб-безопасность.
  • поддержка JAX-RS в качестве расширения
  • класс-ориентированный API, который предсказуем, легко расширяется и настраивается (в Java, XML, Spring, Groovy, Scala и т.д.) с поддержкой аннотаций Java, когда это действительно полезно
  • и др.

Посмотрите на проект и попробуйте: http://www.restlet.org/

Ответ 5

Это не в вашем списке, но я бы порекомендовал resteasy для создания ваших веб-сервисов, которые довольно просты в использовании... просто нужно использовать аннотации к методам доставки веб-сервисов, а также все, что вы написали, что хотите.

Кроме того, если u хочет хорошую интеграцию EJB, вы можете использовать resteasy с JBoss Seam Framework