No hay nada mágico en REST. Como cualquier otra arquitectura, tiene ciertas propiedades y ciertas restricciones. Si necesita esas propiedades y puede vivir con las restricciones, entonces debería considerar implementarlas. De lo contrario, no te preocupes por eso.
REST tiene las siguientes propiedades interesantes:
- REST no tiene estado. Esto es muy importante para el rendimiento y para la flexibilidad de back-end. Si no necesita la escala de Internet, entonces esto es menos interesante. Si está creando un servidor de juegos para 8 jugadores, no le importa. Si está creando Google (o algo que podría convertirse en Google), entonces esto podría ser esencial. Por el contrario, la mayoría de las arquitecturas RPC restringirán sus opciones de fondo. No podrá realizar una conmutación por error a una máquina diferente en medio de una sesión, por ejemplo.
- REST tiene una representación uniforme. Al igual que es posible escribir un explorador de archivos (que puede examinar cualquier tipo de archivo), es posible escribir algo que pueda acceder a un conjunto heterogéneo de interfaces REST. Esto ayuda a desacoplar el cliente del servidor y, por lo tanto, aumenta la robustez y flexibilidad del sistema.
- REST es un patrón de diseño bien entendido. Existe una gran experiencia en el mundo real con los sistemas REST y puede obtener rápidamente consejos sobre cómo se puede representar un dominio de problema particular. Esto lo ayudará a escribir su sistema correctamente desde el principio. En contraste, con un sistema RPC construido a mano, las debilidades (por ejemplo, problemas de extensibilidad) pueden no ser obvias hasta que el sistema esté en producción.
- REST impone ciertas restricciones que resultan en API más limpias y más extensibles. Así como los lenguajes de programación modernos te impiden usar gotos por todas partes, REST restringe los efectos secundarios y las dependencias. Por ejemplo, cuando realiza una llamada API, no tiene que preocuparse de que haya olvidado una condición previa o se haya olvidado de liberar un recurso. Ningún concepto es válido en REST, mientras que una API RPC podría tener esos problemas.
No permita que alguien lo obligue a usar REST si no necesita estas propiedades o si no puede vivir con las restricciones.
- Si tiene una aplicación telefónica que se comunica con un dispositivo IoT, ¿cuál es la mejor manera de determinar qué protocolo se está utilizando?
- ¿Qué puedo usar para enviar todos los paquetes TCP simultáneamente a través de 2 conexiones de forma redundante?
- ¿Qué protocolo usa Traceroute?
- ¿Cuáles fueron los principales efectos de Kerberos (el protocolo de autenticación mutua)?
- ¿Cuáles son los pros y los contras de MQTT versus CoAP como protocolos IoT para dispositivos con recursos limitados?
Pero si no comprende por qué REST sería útil en absoluto, entonces es posible que no comprenda completamente REST o los problemas que está diseñado para abordar.
