xml - elaborando - ¿Cómo debería crear una API REST usando Rails 3.0?

ruby on rails 5 rest api

Question

Parece que no puedo encontrar mucha información en la web sobre los diferentes enfoques para construir una API REST en Rails; así que tengo dos preguntas:

1. ¿Puede alguien señalarme algunos artículos que muestran los pros / contras de los diferentes enfoques?
2. ¿Podría compartir sus opiniones sobre los pros / contras de los siguientes enfoques?

Enfoques propuestos

1. Utilice los controladores estándar para devolver XML cuando un usuario agregue .xml al final de la URL

   Pros:

   • Esto está incorporado en Rails y es muy fácil de usar
   • Sigue el mismo enfoque basado en recursos que tiene Rails, por lo que será fácil para los usuarios existentes comprender / recordar

   Contras:

   • La API no está limpiamente separada del sitio principal, es más difícil de mantener
   • La gente puede suponer que agregar .xml funcionará en lugares donde no funciona

2. Utilice el enrutamiento con espacios de nombre para crear controladores de API separados que solo manejen las funciones de API, pero que aún tengan acceso a los mismos modelos que usa el sitio web.

   Pros:

   • API está mayoritariamente separada
   • Todavía usa controladores de recursos completos

   Contras:

   • Las URL tienen la forma de site.com/api/resource.xml, lo que puede hacer que las personas asuman que todos los recursos están disponibles
   • API sigue siendo parte del código / proyecto del sitio web; por lo tanto, más difícil de mantener

3. Utilice el enrutamiento de ruta y las restricciones para reenviar todas las llamadas API a una aplicación Rack

   Pros:

   • API está completamente separada
   • No se requiere el uso de un estilo de recursos completos si no queremos
   • Las URL muestran claramente que es una API y debes consultar los documentos para ver qué hay disponible (al menos, mi mente funciona de esta manera; supongo que también lo hacen las demás).

   Contras:

   • Más difícil de usar los modelos del código del sitio web
   • Más fácil de mantener como un proyecto separado, pero eso significa más difícil de integrar con el sitio existente
   • Debe mantener las bases de código sincronizadas, ya que los modelos pueden cambiar por las características del sitio / corrección de errores

Answer 1

Creo que la mejor solución para ti es unir tus dos primeros puntos.

Sugiero usar JSON en lugar de XML: el único punto a favor de XML es XPath, que es inútil en los datos devueltos. JSON lleva a un mejor tiempo de respuesta (¡y datos más legibles para una mejor depuración!: P). Además, la mayoría de los idiomas pueden leer JSON. Por ejemplo, PHP puede analizar de forma nativa JSON a array / object con json_decode , por lo que es un buen punto. ;)

Para los controladores, puede usar el espacio de nombre pero no es una obligación, tal vez es mejor en ciertos casos evitar acciones gordas con toneladas de condiciones. Con el enrutador Rails 3, la separación de llamadas API en un subdominio (api.webapp.com) es trivial).

Para el modelo, asegúrese de usar el mismo que se utilizó en toda la aplicación.

La nueva sintaxis del enrutador de rieles es azúcar, disfrutarás. ¡Buena suerte, diviértete! :)

Answer 2

Yo propondría que la API que está en el mismo proyecto que su sitio web no es algo malo, siempre y cuando el código sea SECO *. Como señaló, tener bases de código separadas es un desafío porque tiene que mantenerlas sincronizadas con cada función / corrección de errores que haga. Es más fácil de mantener si están en el mismo lugar. Mientras mantenga su código SECO, este método es el claro ganador.

Ofrecería XML y JSON de los controladores con un subdominio manejado por el motor de enrutamiento de Rails. Cuando alguien ha recogido el patrón de api.site.com/resource.xml e intenta acceder a un recurso que no está allí, realmente no es un gran problema. Siempre que su API esté documentada claramente y falle o falle con elegancia cuando intenten acceder a un recurso que no esté en su API, debería estar bien. Intentaré devolver un mensaje que diga que el recurso no está disponible y una url a su documentación de API. Esto no debería ser un problema de tiempo de ejecución para ningún consumidor de API, ya que esto debería ser parte del descubrimiento de su API.

Solo mi $ 0.02.

* DRY = No se repita. El código DRY significa que no copie ni pegue ni reescriba lo mismo para su sitio y su API; usted extrae y llama desde múltiples lugares.