Es REST adecuado para grandes modelos de 3NF

Question

Existen muchos ejemplos del uso de REST con modelos de datos simples. Por ejemplo, un cliente con 5 propiedades y una colección de pedidos con 6 propiedades. Sin embargo, me es difícil visualizar usando REST contra un modelo que es más complejo, que puede encontrar en compras gubernamentales, finanzas, administración de registros médicos, etc. ¿Hay ejemplos de REST que se usa como la API principal en entornos de LOB grandes?

¿Quizás estoy pidiendo demasiado del enfoque REST?

Answer 1

Estoy construyendo una interfaz REST que actualmente cuenta con más de 250 recursos. Para cuando termine, espero tener más de 1000. Esta es una aplicación ERP que cubre contabilidad, inventario, ventas, costos de mano de obra, ingeniería, etc.

El tamaño o la complejidad de un solo recurso no está directamente relacionado con REST pero más una preocupación de los tipos de medios. Elegí tomar la ruta de definir mi propio tipo de medios ya que también estoy creando el cliente y la interfaz no es para el consumo público. Elegir el mejor tipo de medio para su situación es probablemente una de las partes más difíciles de diseñar una interfaz REST.

Desafortunadamente, la mayoría de la gente parece apuntar en la decisión de medios/tipos y elige la aplicación genérica/json o application/xml y luego usa javascript descargado en el navegador para interpretar el formato. [1] Eso funciona siempre que el único cliente que tenga sea un navegador y no desee que nadie más vuelva a usar su interfaz. Para mí, parece vencer uno de los principales objetivos de REST, es decir, la reutilización fortuita debido a un acoplamiento flexible y formatos estandarizados.

Para explicar mejor lo que quiero decir con esto, considere el caso donde entrega application/json o application/xml a una aplicación cliente. Tan pronto como la aplicación del cliente llegue a ese formato genérico y capture una pieza específica de datos, está creando un acoplamiento oculto entre el cliente y el servidor. Si, en cambio, utiliza el formato de medio "application/vnd.mycompany.myformat + xml", está definiendo explícitamente un contrato con el cliente. Esto tiene una gran ventaja cuando realiza cambios en el formato y tiene la opción de crear "application/vnd.mycompany.myformatV2 + xml"

Las personas perciben que REST es una interfaz poco específica, pero en realidad no es . Una interfaz REST debe ser muy explícita en los tipos de medios precisos que devuelve y espera recibir. Los tipos de medios son el contrato. Si recibe application/xml y utiliza el código de cliente para retirar/Customer/Name, está incumpliendo el contrato.

Las aplicaciones web que usan javascript descargado pueden consumir "aplicación/xml" porque los detalles del contrato no se compilan en el cliente. Sin embargo, el comportamiento del cliente está extremadamente limitado a hacer cualquier cosa que el javascript haya sido preprogramado para hacer. Desafortunadamente, la mayoría de las interfaces RESTful públicas ignoran esta restricción y las personas crean clientes estrechamente relacionados con un contrato no especificado. Es por eso que cuando Twitter cambia su formato, muchos de los clientes se rompen.

Answer 2

REST es adecuado siempre que exista una ruta descriptiva razonable para describir los datos que desea alcanzar.

REST no se siente tan RESTful cuando lo que está tratando de lograr es publicar una API, PERO, me gustaría señalar que las API que se han desarrollado utilizando la filosofía REST han tenido mucho éxito.

Según su descripción, está trabajando con datos, que se deben adherir muy bien a REST, sin importar cuán complicada sea la estructura. REST no prohíbe los esquemas de publicación, por lo que es posible que desee considerar eso también.

Answer 3

REST es un estilo arquitectónico, no una representación de los datos. En general, hoy los datos están representados en XML o JSON, que han sido probados en batalla y pueden soportar fácilmente los grandes modelos complejos a los que se refiere.

En su forma más básica, REST es simplemente los verbos HTTP para controlar un "recurso". La representación de ese recurso puede ser tan simple o tan compleja como lo necesite. El CRUD y la lista de operaciones son las más directas. Las API adicionales y más complejas también se pueden generar fácilmente en este contexto.