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

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.

De estructura básica resto es como sigue:

1. /gatos
2. /gatos/1
3. /gatos/1/encargo

'a medida' se puede 'niño' por ejemplo.

mismo ocurre con:

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

Estos son perfectos para las entidades de la API porque la aplicación móvil definitivamente usará toda esta funcionalidad.

Así que 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.

Lo que más 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 la creación de los siguientes módulos:

1. -api comunidad
2. comunidad web

Api parece ser el núcleo a continuación. 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.Así que, básicamente, la API se vuelve más como una puerta de entrada al núcleo y pensé que necesita esta:

1. núcleos comunidad
   • Modelos
   • Cronjobs
   • Auto correspondencia (parte de cronjobs)
     • Facturas, etc.
2. -api comunidad
   • Interactuar con los modelos en el núcleo a través de HTTP
3. comunidad web
   • sitio web
   • administración

La tarea programada núcleo s 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-core
   • Modelos
2. -api comunidad
   • Interact con los modelos en el núcleo a través de HTTP
3. negocios
   • cronjobs
   • Auto Mailings (parte de cronjobs)
     • Las facturas de la comunidad, etc.
4. comunidad web
   • sitio web
   • administración

Esto se ven mejor por diseño para mí. Mindmap illustration http://mauserrifle.nl/mindmap.jpg

principales cuestiones

1)

caso cronjobs manipular a través de la API o modelos Core?

2)

Mi factura tarea programada necesita una plantilla de más o menos el estilo de la página web principal del curso. 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 va a utilizar el bigote como un motor de plantillas. (Tanto php como javascript pueden analizar estas plantillas). Pensé en usar la API directamente para las llamadas ajax, pero luego me di cuenta:

El sitio obtiene datos de la API, formatea los sellos de tiempo con las fechas (Y-m-d) 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 .... llamadas simples como la eliminación de un anuncio puede ir a través de la API directamente (por ejemplo, suprimir:/Clasificados/1

consigo una mezcla de llamadas ....

Cualquier solución mejor para este

4)

general:? Es mi arquitectura demasiado complejo? ¿Alguna alternativa que deba considerar?

¡Me gustaría escuchar sus comentarios!

Answer 1

Una vez que he oído que una buena forma de desarrollar una aplicación web es desarrollar un API-Centric Web Application. 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.

Answer 2

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 debe ser un cliente de la API en sí, pero como simplificará las cosas, creo que debería REUTILIZAR las clases de dominio para construir 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, debe estar en un recuadro separado si es posible reutilizar 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.

Sus trabajos cron sólo deben usarse para disparar la llamada a través del propio API y las llamadas se deben hacer en la aplicación principal (página web a través de la API)

Si usted construye su sitio web sin tener que repetir usted mismo, como en, utilizando el mismo código que la base y envolviendo la aplicación web a su alrededor, no tendrá el problema planteado 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 3

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.