¿Cuáles son los inconvenientes de usar las API RESTful?

Las API RESTful se basan en los URI que hacen referencia a los recursos. Los URI son convenientes para las solicitudes http y el almacenamiento en caché, pero no son adecuados para los recursos que no se organizan de forma natural ni se accede a ellos en una jerarquía simple.

Por ejemplo, una solicitud como “Devolver todos los registros actualizados de las últimas 3 horas que contienen la palabra gato” no se presta para expresarse como una ruta, por lo que es probable que tenga que implementarse con alguna combinación de ruta URI, parámetros de consulta , y quizás solicite cuerpo.

Las API RESTful generalmente se basan en algunos métodos http (GET, POST, PUT, DELETE, quizás PATCH), pero muchas operaciones comunes de cliente / servidor solo pueden ser torpemente insertadas en los métodos estándar. “Mover documentos caducados a la carpeta de archivo” es un ejemplo de un verbo personalizado específico de la aplicación que está fuera de los métodos http típicos y las operaciones CRUD.

La naturaleza apátrida es en la práctica a menudo un mito. Las API REST terminan dependiendo de los encabezados por estado (como para enrutar solicitudes posteriores al mismo servidor de fondo que manejó la actualización anterior o para la autenticación). El uso de encabezados es torpe y vincula la API a http como transporte.

La confianza en las API RESTful es una desafortunada consecuencia del éxito de http y la infraestructura de Internet relacionada. Un enfoque más general para las solicitudes y respuestas, como el uso de JSON-RPC, permite un diseño API más expresivo y menos engorroso.

Descanso real es demasiado difícil

Los servicios verdaderamente RESTful simplemente requieren demasiado trabajo para ser prácticos para la mayoría de las aplicaciones. Demasiado trabajo del proveedor para definir y admitir tipos de medios personalizados con relaciones modeladas complejas transmitidas en banda. Demasiado trabajo para los clientes y los autores de la biblioteca para realizar una agregación compleja y una nueva formulación de datos para que se ajuste al estilo REST real. Real REST es ideal para arquitecturas genéricas y de proveedores múltiples que necesitan la flexibilidad y capacidad de descubrimiento que proporciona. Para la mayoría de los desarrolladores de aplicaciones es simplemente una exageración y un verdadero dolor de cabeza de implementación.

En general, creo que los inconvenientes (así como los beneficios) solo pueden aprenderse a partir de la comparación de algunas alternativas, ya que depende en gran medida de los objetivos que se esfuerza por alcanzar.

Hay dos informativos increíbles que comparan REST y SOAP, así como también discuten los casos en los que tiene más sentido usar cada protocolo.

El primero: REST vs SOAP – Siente la diferencia .

El segundo está más enfocado en las aplicaciones web móviles: Elegir un formato para servicios web móviles: REST / JSON vs. SOAP / XML .

¡Con suerte, te serán útiles!

La idea de las API RESTful es genial: básicamente dice que puede usar HTTP (S) para implementar el paso de mensajes sin estado en un sistema distribuido, y sugiere usar verbos HTTP estándar (GET, PUT, DELETE, etc.) para realizar operaciones en “recursos” que pueden especificarse utilizando URI jerárquicos.

Pero, básicamente, esto se reduce a “usar el protocolo HTTP correctamente”. Hay casi cero contenido más allá de eso. Parafraseando a Marshall McLuhan en Annie Hall , cómo alguien obtuvo un doctorado por este trabajo es totalmente sorprendente.

Aún así, los conceptos REST son útiles al implementar una API que debe ser utilizada por humanos y máquinas. Es bueno usar un navegador o curl o lo que sea para hacer un GET de un URI, especialmente si la carga está en un formato legible para humanos como JSON.

Creo que la desventaja de REST es que obliga a los debates semirreligiosos sobre cuándo PUT o POST es más apropiado, y en sus formas más ortodoxas intenta prohibir POST por completo. Pero POST es el verbo más útil para la comunicación máquina-máquina, ya que le permite enviar una solicitud arbitraria para efectuar un cambio de estado en el servidor. Esto se puede usar para implementar operaciones de tipo RPC a las que se pueden enviar varios argumentos bien estructurados y bien escritos.

Sin POST, todo lo que tienes es “verbo + cadena de recursos”. ¿Te imaginas programar si todo lo que tuvieras fueran 5 funciones, cada una de las cuales tomó un solo argumento de cadena? Sería una pesadilla. Los programadores tendrían que luchar contra formas de codificar la lógica en el espacio de nombres global único. Muy pronto alguien idearía un esquema de codificación para representar un nombre de función arbitrario más argumentos (como una cadena codificada en base 64 o algo así) y simplemente implementaría sus interfaces por encima de esa capa. Sería totalmente tonto.

La peor parte de la religión REST de “verbo + recurso” es que no se presta a lenguajes de definición de interfaz (como WSDL) o código RPC generado automáticamente porque es complicado especificar acciones y recursos en el espacio de nombres único. Es cierto que es bastante fácil escribir código HTTP cuando solo tienes 5 acciones, pero todo el trabajo duro se dedica al código de envío personalizado para analizar URI arbitrarios. Con el enfoque RPC más tradicional, puede escribir su interfaz utilizando acciones de aribtrary y tipos de datos estructurados, y dejar que la generación de código se encargue del código repetitivo feo.

Puede implementar RPC usando verbos HTTP si lo desea. JSON también funciona bien. Use PUT y DELETE, si flota su bote. Simplemente no veo qué RESTfulness te compra además de eso, o incluso lo que realmente significa.

Principales inconvenientes

REST no puede hacer llamadas asincrónicas

Las sesiones no se pueden mantener