php - programacion - API como núcleo para un sitio web y una aplicación móvil

desarrollo de aplicaciones para android. edición 2018 pdf

Question

Tengo diferentes preguntas sobre una idea de arquitectura completa. Espero que alguien con gran experiencia pueda ayudarme porque me estoy quedando atrapado en todas las posibilidades.

Estoy planeando reescribir un sitio web de la comunidad. Nuestro cliente quiere hacer uso de aplicaciones móviles nativas en el futuro. Por lo tanto, tendré que tener esto en cuenta. Debido a esto, he decidido crear una arquitectura de API REST 100% basada en el framework PHP Kohana. He elegido Kohana porque esto hace que escalar la API interna a otro servidor muy fácilmente sin mucho esfuerzo adicional. (Kohana amenaza las solicitudes de URL internas no como HTTP, por lo que no hay demasiados gastos generales al principio y puede escalar a HTTP con algunos cambios de código menores).

Al principio, la API será privada, pero más adelante podríamos hacerla pública para permitir que más servicios se conecten a nosotros fácilmente.

La estructura REST básica es la siguiente:

1. / gatos
2. / gatos / 1
3. / cats / 1 / custom

''personalizado'' podría ser ''hijos'', por ejemplo.

lo mismo vale para:

1. / anuncios
2. / ofertas
3. / usuarios
4. / banners
5. etc.

Estas son entidades perfectas para la API porque la aplicación móvil definitivamente usará toda esta funcionalidad.

Entonces, podemos concluir que el núcleo del sitio web es REST. Así que básicamente quiero hacer que el sitio web sea un cliente de la API al igual que la aplicación nativa en el futuro. De esta forma, el mantenimiento parece mucho más fácil.

Sin embargo, lo que me preocupa es el hecho de que hay mucho más que esto (gestión de archivos cargados, facturación, automails para facturación, automails para anuncios, etc.). La carga de archivos debe pasar por el sitio web a la API. ¿Es esta práctica común? Si no hago esto, el sitio web cargaría la lógica, lo que hace que el sitio ya no sea cliente y la aplicación misma. Por lo tanto, la aplicación móvil no puede cargarse y tanto la API como el sitio web deben conocer la carpeta de carga (lógica duplicada).

Pensé en crear los siguientes módulos:

1. comunidad-api
2. sitio web de la comunidad

Api parece ser el núcleo entonces. Pero ... ¿qué hay de los cronjobs, etc.? En realidad, no deberían formar parte del sitio web, ya que este es solo un ''cliente''. Siento que deberían interactuar directamente con el modelo o la API. Básicamente, la API se parece más a una puerta de entrada al núcleo y pensó que necesitaba esto:

1. comunidad-núcleo
   • Modelos
   • Cronjobs
   • Envíos automáticos (parte de cronjobs)
     • Facturas, etc.
2. comunidad-api
   • Interactuar con modelos en core a través de HTTP
3. sitio web de la comunidad
   • Sitio web
   • Administración

Los cronjobs centrales son una excepción a la estructura REST. Ellos son los únicos que pueden cambiar los datos sin pasar por la API. Al menos esa fue mi idea porque pertenecen al núcleo y API está en la parte superior del núcleo.

Pero por diseño eso parece simplemente incorrecto. ¡La manipulación solo debe pasar por la API!

Alternativa:

1. comunidad-núcleo
   • Modelos
2. comunidad-api
   • Interactuar con modelos en core a través de HTTP
3. negocio de la comunidad
   • Cronjobs
   • Envíos automáticos (parte de cronjobs)
     • Facturas, etc.
4. sitio web de la comunidad
   • Sitio web
   • Administración

Esto se ve mejor por diseño para mí. Ilustración de Mindmap http://mauserrifle.nl/mindmap.jpg

Preguntas principales

1)

¿Los cronjobs deberían manipularse a través de los modelos API o Core?

2)

Mi factura cronjob necesita una plantilla más o menos del estilo del sitio web principal, por supuesto. Pero si mi cronjob es parte de un negocio o núcleo, no tendrá conocimiento de mi sitio web principal. ¿Qué sentido tiene resolver esto?

3)

Mi sitio web usará bigote como motor de plantillas. (Tanto php como javascript pueden analizar estas plantillas). Pensé en usar la API directamente para llamadas ajax, pero luego me di cuenta de lo siguiente:

El sitio obtiene datos de la API, formatea marcas de tiempo y fechas (Ymd) para la plantilla y luego los renderiza. Si dejo javascript llamar directamente a la API, JavaScript también debe tener lógica (formateo). Este es un código duplicado! Siente que la única solución es llamar al sitio web para ajax (que llama a la API y a los formatos) y devuelve el json formateado. ¿Estoy en lo cierto?

Pero ... las llamadas simples como eliminar un anuncio pueden pasar directamente por la API (por ejemplo, DELETE: / ads / 1)

Recibo una combinación de llamadas ...

¿Alguna mejor solución para esto?

4)

En general: ¿mi arquitectura es demasiado compleja? ¿Alguna alternativa que deba considerar?

Me encantaría escuchar tus comentarios!

Answer 1

Esto no me parece lógico.

Sí, la API y el sitio web y lo que pueda venir a continuación son cosas separadas y el sitio web debería ser un cliente de la API en sí, pero como simplificará las cosas, creo que deberías REUTILIZAR las clases de dominio para crear y basar la lógica de su sitio web. De esta forma, puede usar la misma base de código y manejar todos sus problemas, incluidos los anuncios, la facturación y, por supuesto, la carga de archivos con facilidad.

Para la API pública, debería estar en un recuadro separado si es posible volver a utilizar las mismas clases de dominio pero con diferentes métodos de autenticación para que cualquier problema que pueda ocurrir no afecte al servicio principal.

Tus trabajos cron solo deberían usarse para activar la llamada a través de la API y esas llamadas deberían realizarse en la aplicación principal (sitio web a través de la API).

Si construye su sitio web sin repetirlo usted mismo, utilizando el mismo código que la base y envolviendo la aplicación web, no tendrá el problema en q # 2.

Lo mismo aplica para la pregunta número 3. Si ajusta el sitio web alrededor de la API, el sitio web puede usar la API sin ser una entidad separada.

Su arquitectura parece compleja, pero si hace estas cosas, será simple. ;-)

¡Buena suerte!

Answer 2

REST es solo una forma de iniciar una solicitud. Su código central que procesa la solicitud no debe estar estrechamente vinculado a la interfaz REST, o HTTP para ese asunto. Aconsejaría diseñar su API REST como un simple mapeador a un archivo de inclusión o algo similar. Su cron podría pasar por alto toda la API REST y simplemente incluir el archivo directamente. Separe la interfaz de solicitud del código que realiza el procesamiento real.

Answer 3

Una vez que escuché que una buena forma de desarrollar una aplicación web es desarrollar una aplicación web centrada en API . La cuestión es que, para mí, si combinas el servicio principal con la API pública y creas una aplicación centrada en la API, perderás el objetivo de desarrollar una API pública.