buena práctica: REST API como la interfaz entre la capa de interfaz y la capa de negocio?

Question

Estaba pensando en la arquitectura de una aplicación web que estoy planeando construir y me encontré pensando mucho sobre una parte central de la aplicación. Como querré crear, por ejemplo, una aplicación de Android para acceder a ella, ya estaba pensando en tener una API.

Dado que querré tener una API externa para mi aplicación desde el primer día, ¿es una buena idea usar esa API como interfaz entre la capa de interfaz (web) y la capa empresarial de mi aplicación? Esto significa que incluso la interfaz principal de mi aplicación accedería a los datos a través de la API. ¿Cuáles son los inconvenientes de este enfoque? ¿actuación?

En términos más generales, si se está construyendo una aplicación web a la que es probable que deba accederse de diferentes maneras, es un buen diseño arquitectónico tener una API (servicio web) como interfaz entre la capa de interfaz y la capa empresarial? ¿REST es una buena "herramienta" para eso?

Answer 1

Parece que tienes dos preguntas allí, por lo que mi respuesta es en dos partes.

En primer lugar, ¿debería utilizar una API entre la capa de interfaz y la capa empresarial? Este es ciertamente un enfoque válido, uno que estoy usando en mi proyecto actual, pero usted mismo tendrá que decidir sobre los beneficios, porque solo usted conoce su proyecto. Posiblemente, el factor más importante a considerar es si habrá suficientes clientes diferentes accediendo a la capa de negocios para justificar el esfuerzo de desarrollo adicional en el desarrollo de una API. A menudo, eso simplemente significa más de 1 cliente, ya que los beneficios de tener una API serán evidentes cuando vengas a cambios de lanzamiento o correcciones de errores.También tenga en cuenta la complejidad añadida, la sobrecarga de mantenimiento del código adicional y los beneficios que podrían derivarse de la separación de la interfaz y las capas empresariales, como una mayor capacidad de prueba.

En segundo lugar, si implementa una API, ¿debería usar REST? REST es una arquitectura que dice tanto sobre cómo se desarrolla el resto de la aplicación como lo hace con la API. No es bueno definir recursos en el nivel API que no se traduzcan en Business Layer. El descanso tiende a ser un buen enfoque cuando quieres que muchas personas puedan desarrollar contra tu API (como NetFlix, por ejemplo). En el caso de mi proyecto actual, hemos optado por XML sobre HTTP, porque no necesitamos los beneficios que generalmente ofrece Rest (o SOAP).

En general, la regla de oro es implementar la solución más simple que funcione, y sin codificarse en una esquina, desarrolle para las necesidades de hoy, no las de mañana.

Chris

Answer 2

Claro, se podría usar REST para eso. Pero primero pregúntate, ¿tiene sentido? REST es una herramienta como cualquier otra, y aunque es buena, no siempre es el mejor martillo para cada clavo. La ventaja de construir esta interfaz RESTfully es que, IMO, hará que en el futuro sea más fácil crear otros usos para esta información, tal vez algo que aún no haya pensado. Si decides utilizar una API REST, tu siguiente pregunta es, ¿qué idioma hablará? He encontrado que AtomPub es una excelente manera para que los procesos/aplicaciones intercambien información, y es muy ampliable, por lo que puedes agregar muchos metadatos personalizados y aún así puedes analizarlos fácilmente con cualquier biblioteca de Atom. Microsoft usa AtomPub en su plataforma de nube [Azure] para hablar entre los productores de datos y los consumidores. Solo un pensamiento.

Answer 3

Mi preferencia reciente, que se basa en J2EE6, es implementar la lógica comercial en beans de sesión y luego agregar servicios web SOAP y RESTful según sea necesario. Es muy simple agregar el pegamento para implementar los servicios web alrededor de esos beans de sesión. De esa manera puedo proporcionar el servicio que tenga más sentido para una aplicación de usuario en particular.

Answer 4

Definitivamente necesitará una capa de servicio web si va a acceder a ella desde un cliente nativo a través de Internet.

es evidente que hay muchos enfoques y soluciones para lograr esto, sin embargo considero que la pauta arquitectónica correcto a seguir es tener un interfaz de servicio bien definido en el servidor al que se accede por la puerta de enlace en el cliente. A continuación, utilizaría POCO DTO (DTO antiguos) para comunicarse entre los puntos finales. El objetivo principal de DTO es proporcionar una representación óptima de su servicio web por cable, sino que también le permite evitar tener que lidiar con la serialización, ya que debe ser manejado de forma transparente por las bibliotecas Client Gateway y Service Interface.

Depende de qué tan grande sea su proyecto/aplicación, quiera o no quiera realizar el esfuerzo de asignar sus DTO a los modelos de dominio de cliente y servidor. Para aplicaciones grandes, el enfoque general sería en el cliente asignar sus DTO a sus modelos de UI y hacer que sus vistas de UI se vinculen a eso. En el servidor, podría asignar sus DTO a los modelos de su dominio y, dependiendo de la implementación del servicio, eso sí.

RESTO es un patrón arquitectónico que para pequeños proyectos que considero una sobrecarga/complejidad adicional, ya que no es tan buen ajuste programattic en comparación con los servicios web RPC/centrada en el documento.En pocas palabras, la idea general de REST es desarrollar sus servicios alrededor de recursos. Estos recursos pueden tener múltiples representaciones que su servicio web debería proporcionar según el tipo de contenido preferido indicado por su cliente HTTP (es decir, en el encabezado HTTP ACCEPT HEADER). Las URL canónicas para sus servicios web también deberían estar formadas lógicamente (p.ej./customers/reports/1 en oposición a/GetCustomerReports? Id = 1) y sus servicios web idealmente devolverían la lista de 'estados válidos que su cliente puede ingresar' con cada uno respuesta. Básicamente REST es un buen enfoque que promueve una arquitectura débilmente acoplada y la reutilización; sin embargo, requiere más esfuerzos de 'adhesión' que los servicios web estándar basados ​​en RPC/Document, cuyos beneficios es poco probable que sean visibles en proyectos pequeños.

Si aún está evaluando qué tecnología de servicio web debe utilizar, puede considerar usar mi open source web framework ya que está optimizado para esta tarea. Los DTO que usa para definir su interfaz de servicios web pueden reutilizarse en el cliente (lo cual no es el caso normalmente) para proporcionar una interfaz fuertemente tipada donde se toma toda la serialización por usted. También tiene la ventaja adicional de permitir que cada servicio web que cree sea invocado automáticamente por los servicios web SOAP 1.1/1.2, XML y JSON sin ninguna configuración adicional para que pueda elegir el punto final más óptimo para cada escenario de cliente, es decir, Native Desktop o Aplicación web, etc.

Answer 5

Hemos tenido suerte haciendo algo como esto en un proyecto. Nuestros servicios web principalmente hacen gestión de contenido estándar, con una alta proporción de lecturas (GET) para escrituras (PUT, POST, DELETE). Entonces, si su capa lógica es similar, este es un enfoque muy razonable a considerar.

En un caso, tenemos una aplicación de reproductor de video en Android (Motorola Droid, Droid 2, Droid X, ...) que es compatible con un conjunto de servicios web REST en la nube. Éstos exponen un catálogo de contenido de video a pedido, permiten la configuración y el desmontaje de la sesión de video, manipulan los marcadores, etc. REST funcionó muy bien para esto.

Para nosotros, una de las ventajas clave de REST es la escalabilidad: dado que las respuestas RESTful GET pueden almacenarse en caché en la infraestructura HTTP, se pueden atender muchos más clientes desde la misma aplicación web.

Pero REST no parece encajar muy bien con algunos tipos de lógica empresarial. Por ejemplo, en un caso envolví una operación de mantenimiento diaria detrás de una API de servicio web. No era obvio qué verbo utilizar, ya que esta operación leía datos de una fuente remota, la usaba para hacer muchas creaciones y actualizaciones en una base de datos local, luego borraba datos viejos, luego se apagaba y le decía a un sistema externo para hacer cosas Así que decidí hacer de esto un POST, haciendo que esta parte de la API no fuera RESTful. Aun así, al tener una capa de servicios web encima de esta operación, podemos ejecutar el script diario en un temporizador, ejecutarlo en respuesta a algún evento externo y/o ejecutarlo como parte de un flujo de trabajo de nivel superior.

Dado que está utilizando Android, eche un vistazo a Java Restlet Framework. Hay un Restlet edition supporting Android. El director de ingeniería de Overstock.com lo elogió hace unos años, y todo lo que nos dijo era cierto, es un marco fenomenalmente bien hecho que facilita las cosas.