¿Se puede utilizar REST API como capa empresarial?


9

Estoy usando el patrón de diseño PHP Codeigniter MVC

y tuve este proyecto con algún tipo de procesos comerciales específicos

En mi aplicación trataré con 2 API REST existentes:

  1. Google
  2. Trello

Se me ocurrió la idea de crear una API REST para actuar como Business Logic Layer (BBL)

que a su vez accede a mis modelos directamente para obtener los datos necesarios para formular reglas comerciales

y controlador con comunicarse con BLL con el cliente REST, ingrese la descripción de la imagen aquí

¿Es ese un mal enfoque para el rendimiento?

¿Es mejor crear 2 capas de modelos, una como Data Access Layer (DAL) y otra como Business Logic Layer (BLL)


REST se utiliza para las interacciones entre componentes. ¡No es una capa arquitectónica! Sin embargo, podría usarse en una arquitectura en capas.
Dave Hillier

La semántica de la pregunta está equivocada. No se puede usar como una capa arquitectónica, pero se puede usar como una interfaz para una capa.
Dave Hillier

Respuestas:


11

El problema que veo con su enfoque es que está creando una API REST para un solo consumidor, sus controladores, y eso es excesivo. No solo agregue una capa solo para pasar datos de una capa a otra, no tiene sentido, creará trabajo para usted sin ningún beneficio adicional.

Una forma (rápida) de hacer que su API sea útil sería si fuera el único punto final que necesitan sus controladores (es decir, su aplicación). Considera esto:

ingrese la descripción de la imagen aquí

De repente, su API REST tiene un propósito, y es proporcionar una interfaz unificada a sus diversos proveedores de datos. Su aplicación no necesita saber sobre Google o la API de Trello, o cualquier otro proveedor de datos que pueda usar en el futuro, solo necesita saber sobre su API REST.

Este diseño, aunque un poco más útil, sigue siendo excesivo si su aplicación es el único consumidor. El objetivo de construir una API REST es exponer una interfaz disponible públicamente para que sus aplicaciones la compartan. Y la clave aquí es la exposición, su API REST estará disponible para el mundo y, por lo tanto, debe ser segura. La autenticación y autorización de API no son tareas simples, si solo una aplicación usa su API, ¿por qué pasar por tantos problemas? A menos, por supuesto, que quieras experimentar y aprender. Si ese es el caso, vaya por todos los medios.

En cualquier caso, el rendimiento no debería ser un problema. Debería agregar una capa adicional, por lo que obviamente habrá algo de sobrecarga, pero si esa sobrecarga será significativa o no depende completamente de su implementación. Si su API REST es el único punto final, entonces probablemente sea una buena idea también ser el único lugar donde se produce el almacenamiento en caché. Y no solo el almacenamiento en caché del lado del servidor, una API REST hace que el almacenamiento en caché del navegador sea un poco más fácil de explotar, y si lo hace correctamente, el rendimiento general de su aplicación puede aumentar, en comparación con un enfoque que no sea REST.

tl; dr: No construyas cosas que no tengan un propósito real (a menos que estés aprendiendo).


Gracias @Yannis Rizos por su respuesta Me gustó su arquitectura y creo que voy por ella, pero una pequeña pregunta, lo que quiso decir con "Aplicación" es un MVC completo o solo VC (Vista y controlador), ya que creo que los controladores tendrán un montón de manejo de código como validación, XHR ... etc. No quiero matarlo con llamadas REST, incluso si serán pocas y el resto de BLL se encargará del resto
Ahmed Samy

¿Y es bueno conectar otra API REST desde mi API REST?
Ahmed Samy

1
@AhmedSamy Su API REST es esencialmente una aplicación diferente, puede obtener datos desde cualquier lugar que desee, incluidos sus modelos y otras API. Tendrá que construir controladores RESTful para él, y tal vez incluso vistas. Su aplicación principal puede llamar a su API REST ya sea a través de sus controladores o mediante sus vistas (a través de Javascript).
Yannis

1

Según su dibujo, parece que debería haber un modelo llamado por su controlador que se ocupe de hablar con Google, recuperar los resultados, formatearlo para su aplicación y luego enviarlo al controlador listo para usar. En otras palabras, todos los detalles específicos de google estarían en ese modelo. Lo mismo para Trello. de esa manera, si necesita agregar más apis para consumir, ha mantenido todo bien y separado.

Este es un pequeño detalle, pero recuerde que en el diseño general de su aplicación, debe tener en cuenta las posibles demoras en el envío / envío de la información del servidor API a su servidor. en otras palabras, asegúrese de que su aplicación no se cuelgue completamente si el servidor trello es lento o está inactivo.

Las API tienen que preocuparse por la seguridad, pero no necesariamente tienen que ser "públicas". muchas API son de empresa a empresa sin nada público.

He leído la mayor parte de este libro, es breve, aún de publicación temprana, y no hay suficientes ejemplos, pero es muy actual, es todo php, y el autor está creando y enseñando activamente sobre apis. http://shop.oreilly.com/product/0636920028291.do

la autora tiene publicaciones relacionadas con php rest api en su blog. http://www.lornajane.net/blog

y asegúrese de leer los comentarios para las publicaciones de la API! en serio te dará una perspectiva muy valiosa.

Sugiérale que busque en Google "hipermedia" y api. es posible que no desee usarlo, pero le mostrará algunas otras técnicas para la creación de API.

Me acabo de unir a los programadores. ¡Votaría esta pregunta si pudiera! la mayoría de las empresas no podrán crear aplicaciones completamente nuevas para consumir o publicar apis. así que proponer las mejores prácticas para integrar apis en los marcos de mvc existentes; esto es realmente importante.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.