Comments 40
Хорошая статья, а если ещё и исходники рабочие — то вообще хорошо. Когда мне нужно было работать с xfire и apachecfx везде были одни и те же примеры.
Но как по мне — spring 3 mvc намного упрощает создание REST вебсервиса.
Но как по мне — spring 3 mvc намного упрощает создание REST вебсервиса.
Никогда к сожалению не работал со spring 3 mvc, но слышал ни раз мнение более опытных коллег, что привязываться к тому что не задокументировано в JSR не совсем хорошо?
Да, исходники точно рабочие — собирал поднимал и минимально тестировал.
Да, исходники точно рабочие — собирал поднимал и минимально тестировал.
Spring это фреймворк. И он следует многим JSR'ам, хочет он того или нет.
Ну, я к тому просто что все используемые в данном примерчике аннотации описаны в JSR-311.
А в spring 3 mvc можно ли обойтись, например, только такими же аннотациями или может какими-то из других JSR и будет ли это удобно?
А в spring 3 mvc можно ли обойтись, например, только такими же аннотациями или может какими-то из других JSR и будет ли это удобно?
Я не пробовал JSR аннотации для вебсервисов, т.к. использую спринговские аннотации, но исходя из того что поддерживаются другие JSR (напр. dependency injection, validation) и из того, что существует Spring-WS, то вполне возможно.
В других случаях для разработчика это очень прозрачно — вместо спринговской аннотации пишется стандартная, которую фреймворк опознает сам.
В других случаях для разработчика это очень прозрачно — вместо спринговской аннотации пишется стандартная, которую фреймворк опознает сам.
Раз уж вы используете Spring, зачем изобретать свой велосипед? Что такое ResponseCreator? Чем не угодил @ResponseBody? И т.д.
От спринга использую только JDBCTemplate, в сервисах самих вроде ничего от спринга нету? Со спрингом знаком к сожалению очень отдалённо. И всё тоже к вопросу: @ResponseBody специфицирована в какой-нибудь JSR? Просто тут не нахожу jsr311.java.net/nonav/releases/1.1/spec/spec.html.
Просто следую совету коллег не использовать фрэймворк специфик штуки.
Просто следую совету коллег не использовать фрэймворк специфик штуки.
Спросите пожалуйста у ваших коллег — к чему такие ограничения?
Вот к примеру про спринг аннотации — фреймворк задает архитектуру, и даже если использовать JSR аннотации, то из-за детской болезни стандартного Dependency Injection'a нашей любимой Java, вы не сможете просто поменяв либу спринга на либу джавы сделать приложение рабочим.
Я считаю что ваши коллеги правы в чём-то, к примеру это подошло бы если бы вы использовали в приложение Java Content Repository (JSR-170 вроде), но программирование такая вещь, что нет вечно эффективного рецепта, и всегда нужно думать, подходит ли конкретно эта вещь в конкретно этом месте.
Вот к примеру про спринг аннотации — фреймворк задает архитектуру, и даже если использовать JSR аннотации, то из-за детской болезни стандартного Dependency Injection'a нашей любимой Java, вы не сможете просто поменяв либу спринга на либу джавы сделать приложение рабочим.
Я считаю что ваши коллеги правы в чём-то, к примеру это подошло бы если бы вы использовали в приложение Java Content Repository (JSR-170 вроде), но программирование такая вещь, что нет вечно эффективного рецепта, и всегда нужно думать, подходит ли конкретно эта вещь в конкретно этом месте.
ну что вы? конечно же надежней запилить свою реализацию, чем пользоваться каким-то там непонятными спрингами :)
Я понял, что вы предлагаете. Просто я не имея практически опыта работы со Spring не могу высказаться ни за ни против, потому могу основываться только на советах. Поработаю со спрингом, тогда решу, нужен он там мне или нет.
На простом «попробовать» полное представление о возможностях инструмента сформируются не сразу, а оно должно быть полным чтобы не делать велосипеды. Вот такие толковые новые книги Pro Spring 3 (Apress) (апрель 2012) и Pro Spring MVC — With Web Flow (Apress) (июнь 2012), в принципе достаточно первой там по MVC тоже есть и вообще там рассматриваются все возможности Spring (ну конечно кроме ответвлений Batch, WS, Data и тд).
>>> не использовать фрэймворк специфик штуки
Я бы не сказал Spring строго фреймворк, часто его называют легковесным контейнером. Дело в том что вся необходимая инфраструктура заведется на простом любом Java веб сервере, и не нужно никаких серверов приложений (вроде JBOSS, Websphere, OC4J и тд) где поддержка стандартов (JSR этих) реализована в самом сервере и часто выйти за границы «зашитого» (ну хотя бы прикрутить последние версии некоторых стандартов с новыми необходимыми плюшками) в контейнер не просто без обновления (или иногда даже хаков) самого контейнера (в это не всегда возможно, обычно по причине бюрократии так как сервера приложений обычно используют всякие крупные и солидные заказчики), имел опыт. Spring гибок, «зашитого» нету, то есть реализацию и комплектацию контейнера мы выбираем сами, это удобно.
Я бы не сказал Spring строго фреймворк, часто его называют легковесным контейнером. Дело в том что вся необходимая инфраструктура заведется на простом любом Java веб сервере, и не нужно никаких серверов приложений (вроде JBOSS, Websphere, OC4J и тд) где поддержка стандартов (JSR этих) реализована в самом сервере и часто выйти за границы «зашитого» (ну хотя бы прикрутить последние версии некоторых стандартов с новыми необходимыми плюшками) в контейнер не просто без обновления (или иногда даже хаков) самого контейнера (в это не всегда возможно, обычно по причине бюрократии так как сервера приложений обычно используют всякие крупные и солидные заказчики), имел опыт. Spring гибок, «зашитого» нету, то есть реализацию и комплектацию контейнера мы выбираем сами, это удобно.
В методе
Лучше:
Так URL будет красивее
Ещё можно параметры в URL привязать к regular expression
Например:
Пропустит:
Не пропустит:
getCustomers не очень по «рестовски» использовать @QueryParamЛучше:
@GET
@Produces(MediaType.APPLICATION_JSON)
@Path("/customers/{keyword}/{orderby}{pagenum}{pagesize}")
public Response getCustomers(@PathParam("keyword") String keyword,
@PathParam("orderby") String orderby, @PathParam("pagenum") String pagenum,
@PathParam("pagesize") String pagesize) {
}
Так URL будет красивее
Ещё можно параметры в URL привязать к regular expression
Например:
@Path("/invite/{uid: [0-9]*}")Пропустит:
example.com/invite/123456Не пропустит:
example.com/invite/abc12345@Path("/customers/{keyword}/{orderby}/{pagenum}/{pagesize}")Нечайно слеши пропустил, так правильно.
а если мне надо просто список кастомеров с сортировкой по фамилии на n-ой странице?
А чем выше URL не подходит? Или я не понял вопроса… Мне только не ясно что за keyword, его опустим.
Получается: example.com/customers/lastname/5/10
Выходит мы хотим получить кастомеров, отсортированных по фамилии начиная с 5 стр, кол-во записей на стр 10
Тоесть нам надо при запросе в базу пропустить
Конечно, параметры к нам приходят в виде строки, так что надо конвертнуть в int.
Получается: example.com/customers/lastname/5/10
Выходит мы хотим получить кастомеров, отсортированных по фамилии начиная с 5 стр, кол-во записей на стр 10
Тоесть нам надо при запросе в базу пропустить
№стр * кол-во записей = 50 записей пропустить и взять 10..skip(50).limit(10)Конечно, параметры к нам приходят в виде строки, так что надо конвертнуть в int.
если вычеркнуть keyword совсем, то все просто, да
другое дело, что keyword используется, например, для фильтрации по той же фамилии (хотя у sergeisirik в сырцах параметры вообще игнорируются)
теперь мой вопрос понятен?
другое дело, что keyword используется, например, для фильтрации по той же фамилии (хотя у sergeisirik в сырцах параметры вообще игнорируются)
теперь мой вопрос понятен?
Да, согласен, так видимо красивее будет. Спасибо, буду использовать такой подход в следующий раз!
А почему вы выбрали Apache CXF? Просто мне кажется Jersey намного быстрее развивается. Оба имплементируют jax-rs
Но Jersey начали пилить ещё в Sun и вот — вот начнут поддерживать JAX-RS 2.0.
jersey.java.net/
Но Jersey начали пилить ещё в Sun и вот — вот начнут поддерживать JAX-RS 2.0.
jersey.java.net/
Так уж сложилось, что мой первый опыт работы с jax-rs был именно с Apache CXF. Не слышал просто, что Jersey лучше, нужно будет попробовать.
А в Jersey есть какая-то замена CXF FIQL?
FIQL, как я понял, не относится к CXF — tools.ietf.org/html/draft-nottingham-atompub-fiql-00. Поддержки FIQL в Jersey я по-беглому не нашёл. Вероятно, она не прописана в JSR. Почитав доку на апаче, я увидел, что это стык JAX-RS и JPA/JDBC, так что имхо нужен отдельныq JSR. Вообще штука интересная по части универсализации запросов.
Автор, горячо советую обратить свой взор на Play! Framework. Вот там REST из коробки и ноль мучений.
UFO just landed and posted this here
Я может чего то не понимаю, но вот:
The JdbcTemplate class is the central class in the JDBC core package. It handles the creation and release of resources, which helps you avoid common errors such as forgetting to close the connection. It performs the basic tasks of the core JDBC workflow such as statement creation and execution, leaving application code to provide SQL and extract results.
Отсюда: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/jdbc.html
The JdbcTemplate class is the central class in the JDBC core package. It handles the creation and release of resources, which helps you avoid common errors such as forgetting to close the connection. It performs the basic tasks of the core JDBC workflow such as statement creation and execution, leaving application code to provide SQL and extract results.
Отсюда: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/jdbc.html
Что-то многовато букв в коде для такой задачи.
По мне так если используется Spring, то можно бы взять от него побольше, то есть реализовать REST на Spring MVC, интеграция в спринговый контейнер более тесная (родная) и вообще удобно. А еще есть вот такая новая штука Spring Data — REST, сам еще не пробовал.
Вообще Spring Data довольно интересный проект, этого спрингу давно не хватало. Spring Data JPA пробовал, впечатления положительные.
Насчёт Spring и Hibernate — есть мнение, что лучше не использовать реализации стандартов, вышедшие до появления самих этих стандартов, а то там буду всякие невозможности мигрировать, vendor lock-up и т.д… Spring JDBC ни к каким особым стандартам никаким боком не касается, так что этого принципа не нарушает.
Не совсем понятно почему комментарий адресован мне, но ответить попробую :) В последние годы Hibernate обычно напрямую не используется, а подключается как реализация JSR 220 или просто JPA, то есть стандарт ORM программирования в Java. При таком подходе в принципе Hibernate можно заменить другой реализацией ORM в случае необходимости.
Про CXF столкнулся тут с интересной особенностью. Может кому то будет интересно: при объявлении нескольких классов сервисов в beans.xml, по умолчанию поиск нужного метода происходит только в первом по списку, если у вас более одного то надо рализовывать ResourceComparator: http://cxf.apache.org/docs/jax-rs-basics.html#JAX-RSBasics-Customselectionbetweenmultipleresources
Sign up to leave a comment.
Реализуем RESTful Web Service на java