Dropwizard - организация вашего проекта, понимание терминологии и т.д.

Я изучаю использование Dropwizard. Я смог следить за руководством по быстрому старту и запускать базовые API REST.

В этой документации существует раздел "Организация вашего проекта".

Он рекомендует организовать ваш проект в следующих частях: project-api, project-client, project-service.

Вот мои вопросы/вопросы:

  • Пожалуйста, объясните, в общих чертах, разницу между "api", "service" и "client".

  • Есть ли пример, который строго следует вышеупомянутому соглашению с помощью dropwizard?

  • "... project-client должен использовать эти классы и HTTP-клиент для реализации полноценного клиента для вашей службы" --- поскольку "project-service" будет иметь API REST, то почему нам нужно использовать HTTP Client?

Спасибо!

ОТВЕТЫ

Ответ 1

  • Dropwizard рекомендует следовать следующей структуре проекта:

    {project_name} (т.е. родительский со следующими модулями)

    • {project_name} -api: должен иметь все объекты value/POJO, которые вы используете в своем проекте.
    • {project_name} -client: должен содержать код клиента, используемый для получения данных из внешнего сервиса отдыха. Может быть исключен, если у вас его нет.
    • {project_name} -сервис: содержит оставшиеся (сервис, конфигурация, ресурсы, дао и т.д.).

  • Вы можете найти этот пример полезен, даже если клиентская часть пуста.

  • Как указано в кратком описании для клиента в пункте 1, если ваш проект имеет какой-либо вызов внешним службам отдыха, тогда связанный (HTTP) клиентский код должен идти внутри клиентского модуля. В противном случае исключить сам модуль.

Ответ 2

1) api - как по имени, это интерфейс/контракт, который определяет как Представление (Pojo -Json/Xml) в проекте. Эти модели определяют ваши контракты API, которые могут быть переданы другому проекту, которые потребляют ваш API.

2) сервис - фактическая бизнес-логика и настойчивость. Представления не обязательно должны быть такими же, как ваши объекты Entity (объекты домена). Это более четкое разделение вашего домена и представлений. Логика домена больше не будет связываться с вашим представлением. Хотя это может вызвать значительное дублирование в плане структуры объекта.

Зависимость от проекта - зависит от "api", "клиент"

3) клиент - оболочка Http Client для вызова других веб-сервисов через HTTP-вызовы с использованием HttpClient или Jersey Client. Написание тестов (для конечного пользователя) для контрактов.

Зависимость от проекта - зависит от "api"

Надеюсь, что это поможет.