Marco de Ruby para escribir una API?

Question

Hola, estoy buscando escribir una aplicación de tareas multiplataforma para técnicos. Quiero manejar tantas plataformas como pueda (web, shell, escritorio) y, por lo tanto, he decidido comenzar con un servidor/API.

Quiero escribirlo en Ruby, sin embargo, creo que Rails es un poco pesado para esto, aunque haría el trabajo. Sinatra tampoco parece muy adecuado para la tarea.

Todo lo que el servidor/API haría sería traducir solicitudes simples a las consultas de la Base de datos, y en una etapa posterior algunas autenticaciones y autorizaciones.

Así que, básicamente quiero saber:

1) ¿Debo usar una API REST o SOAP API?

2) ¿Hay un marco para esto? ¿O cuál es el marco más cercano disponible?

Answer 1

Para los aventureros, también hay un proyecto menos conocido llamado grape. Es una aplicación basada en rack, similar a Sinatra, pero solo tiene el propósito de escribir API. No creo que todavía esté lo suficientemente maduro como para ser utilizado en proyectos serios, pero aún así es interesante saberlo.

Answer 2

1) REST, SOAP es un sistema terrible y su soporte en Ruby es bastante deficiente. REST, por otro lado, es básicamente el valor predeterminado de ruby ​​y requiere muy poco esfuerzo de uso, especialmente si está utilizando REST/JSON.

2) Sinatra y los rieles son básicamente sus opciones. Todo se reduce a la complejidad de esta aplicación. Sinatra probablemente pueda encargarse de la tarea, pero Rails hace gran parte del trabajo por usted a expensas de la hinchazón. Ya utilizará parte de la hinchazón de los rieles si usa ActiveRecord para la base de datos. Cuando la autenticación y/o los roles entran en juego, Rails tiene soluciones maduras para ambos. Sin información adicional, me inclinaría hacia Rails ya que hace gran parte del trabajo por usted y, cuando se escribe correctamente, puede ser bastante rápido.

Answer 3

En realidad, SOAP es muy MUY fácil de implementar con AWS. Al mismo tiempo, API REST también es muy fácil de implementar. He escrito un par de API diferentes y paralelas (JSON, XML y formato personalizado) con rieles. Estoy seguro de que el rendimiento de la pila del framework no será tu cuello de botella, así que no te preocupes por preocuparte por el rendimiento todavía. Su primer cuello de botella será, de todos modos, base de datos y tal vez solicitudes por segundo.

En general, le sugiero que vaya con Rails, tiene mucho trabajo para usted.

Answer 4

Dado que este hilo viejo todavía aparece en las búsquedas de Google relacionadas, debería incluir mi recomendación altamente sesgada (como coautora y usuaria) para Hoodoo. A diferencia de otras ofertas, Hoodoo incluye un API specification que dice cómo deben hacerse las llamadas API y cómo deben responder; impone una coherencia a través de su diseño que los clientes de llamadas apreciarán. Si puede llamar a una API, puede llamarlos a todos. Hoodoo implementa una gran cantidad de repeticiones para que pueda enfocarse en un código de servicio significativo.

Hemos estado utilizando los servicios de Hoodoo durante más de dos años con gran éxito en Loyalty New Zealand, que ejecuta el programa de lealtad más grande del país. Nuestra plataforma de microservicio basada en Hoodoo maneja el 100% de las transacciones de nuestros clientes.

• http://hoodoo.cloud/
• https://github.com/LoyaltyNZ/hoodoo
• https://github.com/LoyaltyNZ/hoodoo/tree/master/docs/api_specification
• https://github.com/LoyaltyNZ/service_shell

Hoodoo tiene cobertura de las pruebas y la documentación rspec rdoc 100% de cobertura no trivial 100%. Como verá en los enlaces de arriba, ¡hay mucho allí!

Hoodoo es Rack application, por lo que funciona con cualquier servidor web compatible con Rack. Sin embargo, nuestro mecanismo de implementación preferido es un acuerdo de escalabilidad indefinidamente horizontal basado en un HTTP-over-AMQP bridge y un clúster de nodos AMQP, cada uno con la misma colección de servicios, administrados dentro de los contenedores Docker y desplegados con Fleet. La autocarga del sistema se equilibra a través de los nodos de servicio a través de la cola y el desacoplamiento del procesador HTTP-> AMQP de la interfaz frente a la entrada AMQP-> HTTP en la pila de Rack reduce drásticamente la superficie de ataque del sistema. Escribimos el componente front-end en Node y para obtener más información sobre esto junto con las implementaciones de Node de otras partes del concepto de framework, consulte el Alchemy Framework. Los servicios Alchemy Node y Hoodoo Ruby pueden coexistir felizmente en la misma red.