jbdi java http rest dropwizard

java - jbdi - io dropwizard



Dropwizard-organizando tu proyecto, entendiendo terminología, etc. (2)

Estoy aprendiendo a usar Dropwizard. Pude seguir la guía de inicio rápido y ejecutar las API REST básicas.

En esta documentation , hay una sección llamada "Organización de su proyecto".

Se recomienda organizar su proyecto en las siguientes partes: proyecto-api, proyecto-cliente, proyecto-servicio.

Aquí están mis preguntas / consultas:

  1. Por favor, explique, en términos generales, la diferencia entre ''api'', ''servicio'' y ''cliente''.

  2. ¿Hay algún ejemplo que siga estrictamente la convención anterior utilizando dropwizard?

  3. "... el proyecto-cliente debería usar esas clases y un cliente HTTP para implementar un cliente completo para su servicio" --- ya que ''proyecto-servicio'' tendrá las API REST, entonces ¿por qué necesitamos usar el Cliente HTTP? ?

¡Gracias!


  1. Dropwizard recomienda que sigas la siguiente estructura de proyecto:

    {project_name} (es decir, padre con los siguientes módulos)

    • {project_name} -api: debe tener todos los objetos de valor / POJO que está usando en su proyecto.
    • {project_name} -client: debe contener el código de cliente utilizado para obtener datos del servicio de descanso externo. Puede ser excluido, si no tiene ninguno.
    • {project_name} -servicio: contiene el restante (servicio, configuración, recursos, dao ... etc).
  2. Puede encontrar this ejemplo útil, aunque la parte del cliente esté vacía.

  3. Como se mencionó en la breve descripción para el cliente en el punto 1, si su proyecto tiene alguna llamada a servicios de descanso externos, el código del cliente relacionado (HTTP) debe ir dentro del módulo del cliente. De lo contrario excluye el propio módulo.


1) api - como por el nombre, es la interfaz / contrato que define como Representaciones (Pojo -Json / Xml) en el proyecto. Estos modelos definen sus contratos de API, que podrían compartirse con diferentes proyectos que consumen su API.

2) servicio - lógica de negocio actual y persistencia. Las representaciones no tienen que ser las mismas que las de los objetos de entidad (objetos de dominio). Esto divide su dominio y representaciones de una manera más clara. La lógica de dominio ya no se unirá a su representación. Aunque esto puede causar una duplicación significativa en términos de estructura de objetos.

Dependencia del proyecto - depende de "api", "cliente"

3) cliente : un contenedor de Http Client para llamar a otros servicios web a través de llamadas HTTP usando HttpClient o Jersey Client. Pruebas basadas en escritura (usuario final) para los contratos.

Dependencia del proyecto - depende de "api"

Espero que esto ayude.