Аннотации JAX-RS: лучше использовать интерфейсы или классы? - PullRequest
13 голосов
/ 08 января 2012

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

Мне кажется, это может привести кв чистом файле класса, но может также привести к тому, что разработчикам придется постоянно путаться между файлами.

Каковы плюсы и минусы каждого подхода?

Ответы [ 3 ]

9 голосов
/ 08 января 2012

Вы должны поместить его в интерфейс. Скорее моя практика требует, чтобы я поместил его в интерфейс, потому что мои клиентская и серверная стороны используют одно и то же определение jax-rs.

Я склонен использовать jax-rs для REST-RPC.

Причина REST состоит в том, что API URL веб-службы может быть исправным и «клиентским» в любой среде программирования.

Использование jax-rs ограничивает нас использованием java на стороне сервера.

Использование jax-rs для REST-RPC ограничивает нас использованием java как на стороне сервера, так и на стороне клиента.

Что такое REST-RPC?

В не слишком запутанном объяснении RPC - это способ вызова функции / метода на клиенте, который при отправке по проводному соединению обслуживается сервером, так что такая же функция / метод существует на стороне сервера.

RestEasy позволяет вам использовать определение jax-rs на стороне клиента для вызова той же функции, обслуживаемой на стороне сервера.

RestyGWT, также с некоторой модификацией интерфейса для указания метода обратного вызова, позволит вам (в некоторой степени) использовать определение jax-rs как на стороне клиента, так и на стороне сервера. Вам просто нужно написать скрипт для перемещения возвращаемого типа в аргумент типа метода обратного вызова.

Вы можете спросить, зачем ограничиваться исполнением java с обеих сторон? Разве это не победит одну из целей в жизни REST? Я думаю, что jax-rs REST-RPC - это удобный путь для реализации и тестирования сервиса jax-rs. Если вы хотите реализовать службу jax-rs, вы, вероятно, в любом случае изначально сделаете это на Java с обеих сторон. А затем, когда ваш сервис начнет работать, вы можете начать писать клиенты на PHP или python.

Запись ваших jax-rs в интерфейсные файлы позволит вам опубликовать ваш интерфейс для операций на стороне клиента. Это особенно верно для REST-RPC. Однако вы можете запустить enunciate поверх определения jax-rs, чтобы опубликовать API-интерфейс веб-службы для не-Java-программистов.

У меня есть постоянные разговоры на эту тему ... http://h2g2java.blessedgeek.com/2011/11/gwt-with-jax-rs-aka-rpcrest-part-0.html.

7 голосов
/ 19 марта 2013

Я думаю, что я должен с уважением частично не согласиться с Блаженным Гиком. То, что упомянуто, является очень специфическим случаем использования, который требует использования аннотаций на интерфейсе.

По моему личному опыту, я сталкивался со случаями, когда фреймворк либо из-за дизайна, либо из-за ошибки не реагировал должным образом на размещение аннотаций в интерфейсе. Например, Apache CXF неправильно обрабатывает запросы @PUT с @PathParams, определенными в пути, когда вы размещаете аннотации на интерфейсе. Не спрашивай меня почему. CXF не одинок в этом; Spring Security имеет аналогичные ограничения при размещении аннотаций на интерфейсах. Так что это противоположность тому, что упоминалось выше

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

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

Другая сторона этой медали (в зависимости от вашего определения интерфейсов) заключается в том, что интерфейсы не должны заботиться о том, какие шаги их разработчики предпринимают для достижения цели, определенной в контракте на метод. Например, зачем размещать аннотацию @Transactional на интерфейсе, если у вас может быть две реализации, одна из которых не знает, что такое «транзакция»?

На практике линии размыты. В случае определения спокойной конечной точки вы можете разместить соответствующие аннотации на интерфейсе. Я думаю, что это имеет смысл в большинстве случаев; у вас, вероятно, не будет нескольких реализаций, в которых одна и та же сигнатура метода отвечает на разные глаголы HTTP. Однако вы можете столкнуться с ситуацией, когда разные реализации предпочитают потреблять и создавать разные типы носителей.

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

2 голосов
/ 11 августа 2013

У меня был похожий вопрос при использовании JAX-RS с JAX-B.Я надеялся использовать аннотации JAX-B на интерфейсах, а не на классах.Это не работает, как я ожидал, причина кроется в unmarshaller.Чтобы решить свои проблемы, я использовал классы. Здесь - описание того, что и что я нашел.

...