Это плохая идея использовать @RequestMapping в интерфейсе?

Question

Я проверил это SO Post , в котором обсуждается использование RequestMapping в интерфейсе. Хотя пост содержит способов достижения этого, но в нем не упоминаются плюсы и минусы этого.

Архитектура мудрая, это плохая идея использовать контроллер в качестве интерфейса? Какую пользу мы получим с точки зрения полиморфизма для контроллера?

Answer 1

Нет ничего плохого в том, чтобы поставить @RequestMapping на интерфейс. Однако убедитесь, что у вас есть правильные причины для этого. Полиморфизм, вероятно, не является хорошей причиной, у вас не будет другой конкретной реализации, замененной во время выполнения, или что-то в этом роде.

С другой стороны, например, Swagger Codegen генерирует интерфейсы с @RequestMapping и всеми аннотациями для методов, полей и типов возврата (вместе с @Api определениями и т. Д.). Ваш контроллер затем реализует этот интерфейс. В этом случае это имеет большой смысл, потому что он просто заставляет вас уважать определение интерфейса Swagger / OpenAPI, изначально определенное в Yaml. Есть хороший побочный эффект, который делает ваш контроллер намного чище. (Клиенты также могут использовать один и тот же Yaml для создания своих собственных клиентских заглушек для своих языковых платформ).

Если вы решите сделать это, убедитесь, что вы используете последнюю версию Spring Framework, потому что были некоторые ошибки, которые были исправлены совсем недавно, когда не все аннотации были унаследованы. https://github.com/spring-projects/spring-framework/issues/15682

Если вы застряли в более старой версии Spring, вам может потребоваться повторить те же аннотации в вашем контроллере.

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

Answer 2

Хотя некоторые аргументы против этого таковы:

• отображение запроса является подробностью реализации, или
• , поскольку у вас есть только одна активная реализация контроллера, вы можете также поставить ее нареализация,
• (другие, вероятно, будут предоставлены в других ответах в ближайшее время)

Недавно я столкнулся с тем же решением поместить аннотации jax-rs в интерфейс или реализацию,Итак, поскольку все всегда «зависит» от некоторого контекста, я хочу дать вам аргумент для установки RequestMapping (или, например, @Path и т. Д., Если не используется spring) на интерфейс:

• Если вы не используете HATEOAS или не обнаруживаете конечные точки с помощью других средств, URL-адрес конечной точки, метод http и т. Д. Обычно являются фиксированными и являются статической частью вашего внутреннего API.Поэтому вы могли бы также поместить его в интерфейс.Это было так для меня, потому что я контролирую и клиент, и сервер.
• Контроллер обычно имеет только одну активную реализацию, поэтому причина этого не в полиморфизме.Но ваша реализация обычно имеет гораздо больше зависимостей, чем простой интерфейс.Поэтому, если вы экспортируете / предоставляете только свой интерфейс для клиентов (например, в отдельном проекте jar / java / ...), вы предоставляете только те вещи, которые действительно требуются клиентам.В моем конкретном случае я поставил аннотированный интерфейс, чтобы клиентская реализация могла использовать его с помощью библиотеки Rest-Client-Library и автоматически определять пути конечных точек.