API REST interna

Question

Actualmente tenemos tres sitios en nuestra red. Uno escrito en Ruby on Rails y los otros dos escritos en PHP. Todos los sitios tienden a compartir muchos de los mismos datos y lógica. Me encuentro teniendo que repetir mucho del trabajo que hago en el lado de los rieles en el lado de PHP. Parece que necesitamos una API interna común para consolidar esto. Nunca antes había creado una API y tengo algunas preguntas.

• Rendimiento Si construyo la API como una aplicación independiente, parece que esto va a ser dos veces más lento. Como debe pasar por todo el ciclo de solicitud/respuesta en el extremo de la API y luego nuevamente en el lado de la aplicación pública. ¿Hay alguna manera de hacer esto más rápido? O tal vez un enfoque diferente?

• Acceso API a través de la red local ¿Cómo accedería a la API a través de la red local? ¿Configuraría un servidor virtual en Apache que apunta a 127.0.0.1?

• Recurso activo En mi caso (en el extremo de los rieles) ¿ActiveResource es la mejor manera de hacerlo o hay mejores opciones para consumir la API? También me pregunto cómo funcionarán las validaciones en el lado público. ¿ActiveResource reutiliza las reglas de validación o tendré que volver a crearlas en el lado público?

• API Security Estoy pensando que no tendré que preocuparme demasiado por esto en este momento, ya que solo se puede acceder a la API (idealmente) a través de la red local. ¿Estoy en lo correcto en esta suposición?

Answer 1

Hay whole books que han abordado este tema en particular. Tratar con la gestión de la latencia, la estabilidad, la flexibilidad y todas las demás -iniciales al crear servicios.

Desde un punto de vista muy general, y el caso de uso relativamente simple que parece que tiene, recomendaría API basadas en REST simples en cada aplicación. Definitivamente no quiere repetir el código en PHP que ya está escrito en Ruby, y viceversa. Los tiempos de respuesta no son muy altos entre los métodos de consulta basados ​​en HTTP (no tan drásticamente como lo haría cuando se habla de algo como HTTP frente a CORBA, de todos modos). Escribir sobre recursos REST es lo que Ruby on Rails es bueno, así que tienes eso como un truco. PHP es un poco más difícil, y solo tienes que estructurar tu API consultable de tal forma que siga los estándares REST. Después de eso, solo necesita un Cliente HTTP para hacer solicitudes contra cualquiera de los clientes. Si tiene puntos finales bien definidos para cada aplicación, no debería ser un gran problema para codificarlos. Si no, hay otro patrón de diseño completo alrededor de enterprise service buses que ayuda a un servicio a encontrar otro, pero generalmente no tiene capacidad de plataforma cruzada (al menos, no PHP hacia y desde Rails-wise-- que yo sepa, que es !).

Para el mundo Ruby/Rails, puedo recomendar HTTParty o Typheous como clientes HTTP (que consultarán el cliente REST de la otra aplicación). Para el mundo PHP, bueno, es posible que desee consultar en this thread. Tiene algunos enumerados.

Para ser claros, esta no es su única opción: puede crear servicios web completos, e incluso profundizar creando conexiones directas de socket, et al. Realmente todo depende de cuán estrechamente acoplados uno quiera que sean los sistemas, cuán estrechamente acoplados puedan ser, cuán cerca están (en un sentido de "topología de red") y qué tan rápido debe ser la respuesta de cada sistema.

En cuanto a la seguridad: Una opción sería configurar su firewall en cada sistema para aceptar solo las conexiones que van a un recurso en particular si son de una IP particular. Podría seguir un patrón similar a nivel de aplicación. Aunque es posible que tenga tanta suerte con la obtención de una sesión HTTPS estándar con autenticación básica/resumida.

Espero que esto ayude. Podría seguir hablando de esto durante mucho más tiempo, pero no sé si hay alguna forma de dar una respuesta específica a esta pregunta de en general. Si hay algo que pueda ampliar, no dude en comentar y lo haré lo que pueda.