Consumir API REST desde la aplicación Rails

Question

Estoy construyendo mi primera aplicación Rails y quiero que consuma todo desde una API REST. Lo que quiero hacer es que Rails sirva mi aplicación web como interfaz para mi API. Por lo que he leído (estoy mirando Rails en este momento), Rails tiene un gran potencial con los ORM y el acceso directo a los sistemas de bases de datos. Mi plataforma, por otro lado, está diseñada de tal manera que se accede a cada capa a través de una interfaz definida (en este caso, una API REST), por lo que no se leen bases de datos desde ningún cliente, sino a través de sus interfaces.

Por ejemplo, mi API expone los siguientes recursos:

https://api.example.com/v1/users/feature-xxx [GET] 

y quiero que mi aplicación web para tener una página como:

https://example.com/feature 

Así los usuarios a visitar este URL y cuando se conecte en, la aplicación Rails solicitará los datos para generar este contenido dinámico de mi API.

La pregunta es:

• Cuáles son los pasos necesarios para mi aplicación Rails para consumir sus datos de un HTTP/Resto del backend? y,
• ¿Es este un buen diseño para una aplicación Rails?

Gracias!

Answer 1

ActiveResource ya no está siendo incluido en Rails 4.0. Word es que apenas se mantiene en estos días, y es difícil de personalizar para los puntos finales de la API REST que no están formulados de acuerdo con el "modo Rails".

Después de algunas investigaciones, estoy muy a favor de usar Faraday. Incluye soporte para utilizar diferentes adaptadores de solicitud HTTP. Puede usar EventMachine directamente, o bibliotecas como Typhoeus para cuando decida concurrir. También es compatible con middleware similar a Rack para que incluya, digamos, autenticación.

Para un REST ORM en rieles que es fácilmente configurable, el relativamente nuevo (alrededor de un año) Her parece muy prometedor, y utiliza Faraday.

actualización

estoy totalmente . Tan sencillo. Si necesita funcionalidad al estilo ORM, necesitará una abstracción de nivel superior, pero para simplemente consumir una API, no puede vencer su simplicidad. Simplemente hace exactamente lo que se supone que debe hacer sin problemas, tiene valores predeterminados razonables y tiene la capacidad de establecer opciones avanzadas como los encabezados de autenticación.

Answer 2

Sí, puede ser un buen diseño.

Mi consejo para que se lea "Diseño orientada a servicios con Ruby y Rails:. http://www.amazon.com/Service-Oriented-Design-Rails-Addison-Wesley-Professional/dp/0321659368

Se centra en reparador de Ruby apps al igual que su ejemplo, con un énfasis en la ampliación y el rendimiento También investiga diferentes marcos (Rack, Sinatra, Pasamanos) y los papeles que llenar bien.

por desgracia no he implementado esta estrategia de mi ser (todavía!), así que no se puede dar ninguna primer consejo mano.

Answer 3

yo recomendaría ActiveResource para su requisito. Mi la experiencia con esto ha sido realmente buena. Siempre que la API que desea consumir sea realmente REST, no creo que haya ningún diseño más limpio para consumir datos a través de REST API. Desde su README,

recurso activo

activos de recursos (Ares) conecta objetos de negocio y Transferencia de estado representacional (REST) ​​ servicios web. Implementa mapeo objeto-relacional para la web REST servicios para proporcionar funcionalidad de proxies transparentes entre un cliente (ActiveResource) y un servicio REST (que es proporcionada por Simplemente REST enrutamiento en ActionController :: Recursos).

Filosofía

intentos recurso activo a proporcionan un mapeo objeto-relacional coherente envoltura para el descanso web servicios. Sigue la misma filosofía que Active Record, en ese uno de sus principales objetivos es reducir la cantidad de código necesario para asignar a estos recursos . Esto es posible gracias al dependiendo de una serie de convenciones basadas en el protocolo code-y que hacen que sea fácil para Active Resource inferir relaciones y estructuras complejas. Estas convenciones se describen en detalle en en la documentación de ActiveResource :: Base.

general

clases de modelo se asignan a recursos REST remotas por recurso activo de la misma manera activa clases del modelo de base de datos de mapas de registro a tablas. Cuando se realiza una solicitud a un recurso remoto , se genera una solicitud XML REST , transmitida y el resultado recibido y serializado en un objeto Ruby utilizable .

configuración y el uso

Poner activo recurso a utilizar es muy similar a Active Record. Es tan simple como la creación de un modelo de clase que hereda de ActiveResource :: Base y proporcionando una variable de clase sitio a la misma:

class Person < ActiveResource::Base 
    self.site = "http://api.people.com:3000/" 
end 

Ahora la clase Person está activado REST y puede invocar servicios REST muy de manera similar a cómo Active Record invoca métodos de ciclo de vida que operan contra una tienda persistente.

# Find a person with id = 1 
ryan = Person.find(1) 
Person.exists?(1) # => true 

Como se puede ver, los métodos son bastante similares a métodos activos de registro para hacer frente a la base de datos registros. Pero en lugar de tratar directamente con un registro de base de datos, , se trata de recursos HTTP (que pueden ser o no registros de base de datos ).

Read more here...

Answer 4

Si decide no utilizar una biblioteca de cliente HTTP como Farady o HTTParty, puede usar open-uri para tomar los datos del punto final que necesita y analizarlos con JSON.

Requisitos: abierto-uri y JSON

En el controlador:

@people = JSON.parse(open("http://api.people.com:3000/people").read, symbolize_names: true) 

En la vista:

<% @people.each do |person| %> 
    Name:<%= person[:name] %> 
    Age:<%= person[:age] %> 
<% end %>