Pros y contras de la arquitectura RESTful [cerrado]

La discusión más común que he visto sobre los pros y los contras de REST tiende a enmarcar esa discusión en relación con SOAP. No tengo experiencia en ninguno de los dos. Actualmente me enfrento a una decisión que mi falta de experiencia me dificulta evaluar. Estoy comenzando a desarrollar una aplicación que tiene varios componentes, principalmente un aspecto administrativo que permite al propietario administrar varios sitios, y una interfaz de usuario pública que permite al usuario interactuar con los datos almacenados en el host. Necesito evaluar las implicaciones de permitir que la última parte se aloje en cualquier lugar y comunicarse con la primera a través de una arquitectura RESTful, o exigir que ambos componentes residan en el mismo host. ¿Cuáles son las implicaciones clave del desarrollo de la arquitectura RESTful, particularmente con respecto a su capacidad en las siguientes áreas:

1: Seguridad 2: Rendimiento 3: Complejidad de la interfaz

EDITAR: Mirando algunas de las respuestas a esta pregunta, debo aclarar. No estoy buscando una comparación con SOAP, sino una descripción general de las aplicaciones REST frente a las aplicaciones donde todos los componentes residen en un host. (¡aunque gracias por esas respuestas!)

Dadas esas áreas, puedo dar una visión general, pero no puedo sacar sus conclusiones para usted. Hay dos áreas principales donde los dos protocolos difieren:

• Formato de mensaje
• Descubrimiento de servicio

El formato del mensaje es más fácil de entender. El paquete SOAP para solicitudes y respuestas es bastante pesado. Existe el sobre SOAP que contiene una sección de encabezado y cuerpo. El encabezado puede ser utilizado por varios filtros en la cadena de solicitud para realizar algún tipo de identificación, autorización, etc. Sin embargo, XML es costoso de analizar, lo que genera una cierta penalización en la escalabilidad de su sistema. Cuánto depende de la capa de procesamiento SOAP en su pila.

El descubrimiento de servicios es donde probablemente tendrá más contención. REST por su propia naturaleza proporciona puntos finales predecibles , y el contenido de la solicitud es una simple solicitud HTTP. El beneficio es que no hay gastos adicionales, y los usuarios finales pueden adivinar cómo hacer lo que necesitan una vez que entienden la estructura de URL de su sitio. Por supuesto, las personas ingenuas conscientes de la seguridad lo verán como una debilidad. Después de todo, con SOAP, debe consumir un WSDL para saber cuáles son los puntos finales. Por supuesto, con SOAP se le dio el formato de mensaje completo para que pueda realizar ataques más específicos.

Desglosado por las categorías que dio:

Seguridad

Ninguno de los dos es inherentemente más seguro que el otro. Use buenos principios de seguridad:

• Cifrar comunicaciones
• Asegúrese de autenticar y autorizar a los usuarios antes de procesar
• Buenos hábitos de codificación para evitar ataques directos.
• Y esa es solo la lista corta.

¡Recuerda la oscuridad! = Seguridad.

Actuación

Tanto el rendimiento sin procesar como la escalabilidad irán a REST debido a la solicitud que sigue a los protocolos HTTP simples. La mayoría de las pilas SOAP utilizan el análisis SAX (análisis basado en eventos) que mejora en gran medida la escalabilidad de las pilas SOAP, pero hay un impacto medible en la sobrecarga. SOAP tiene la sobrecarga de procesamiento HTTP normal además de la sobrecarga de análisis XML. REST solo tiene la sobrecarga de procesamiento HTTP.

Complejidad

Desde la perspectiva del sistema, REST gana. Hay menos piezas móviles, una cadena de solicitud más ágil, etc. Eso significa que es más fácil hacer confiable.

Desde la perspectiva del programador, SOAP puede ganar si el IDE o el marco que está utilizando le brinda un buen soporte. Esencialmente, con REST le corresponde a usted realizar el trabajo de preprocesamiento (autenticación / autorización / etc.), mientras que con SOAP se puede lograr mucho con una cadena de procesamiento conectable.

Mi preferencia

Me siento muy cómodo con las solicitudes HTTP y sé cómo funciona la web. Como resultado, el enfoque REST es más preferible para mí. Sin embargo, sé que algunos de mis clientes se sienten incómodos con eso. Han leído algunos artículos de la industria que denuncian la seguridad de REST frente a SOAP, etc. La conclusión es que ninguno de los enfoques garantiza la seguridad. Depende de usted asegurarse de que la aplicación sea tan segura como sea necesario. Obviamente, una aplicación web social no exige (o desea) tanta seguridad como un sistema bancario o gubernamental. Muchas pilas SOAP incluyen procesadores que puede conectar para proporcionar una apariencia de seguridad, pero aún es su responsabilidad buscarlos y ponerlos en su lugar.

1. Seguridad: use HTTPS. Esto se aplica a ambos.
2. Rendimiento: . REST es menos costoso para la CPU (menos análisis, clasificación, desempaquetado). Además, el almacenamiento en caché con REST es pan comido.
3. Complejidad: REST exige mucho menos en términos de configuración, es solo GET / POST después de todo. SOAP requiere mucha más administración para mantener (wsdl, etc.), pero es un poco más fácil si su IDE lo admite.

Creo que SOAP está demasiado hinchado cuando puedes hacer lo mismo con REST y algunos tipos de contenido / mime. Además, SOAP trae mucha sobrecarga, debido a su naturaleza de envoltura de envolturas y al hecho de que es más general y no se limita a HTTP. SOAP es tentador de usar si su IDE lo admite correctamente y no desea aprender HTTP. Pero para mí, REST es mucho más fácil de usar y mucho más amigable con la web.

Hoy en día, hay muy buenas API REST para usar. Si te gusta Java, entonces Jax-RS es realmente genial. Para algunas personas, esto es como el porno.

Creo que la mayor ventaja de REST es romper con las arquitecturas RPC. REST expone recursos, no procesos. Eso le permite crear un sistema débilmente ligado, donde los cambios, las mejoras, incluso las fallas de una parte tienen un impacto limitado (negativo) en otras partes.

Desafortunadamente, un mal uso común de REST es exponer sus estructuras de datos internas (en el peor de los casos, es un CRUD de su base de datos, ugh). Eso hace que sea muy difícil hacerlo de manera segura. El uso "correcto" es exponer objetos de alto nivel que sean relevantes para la parte del sistema que está manejando, y generosamente devolver códigos de estado de error ante cualquier inconsistencia.

Otra parte de REST que a menudo se pasa por alto es la idempotencia de la mayoría de los verbos. No solo GET, sino también PUT y DELETE deben ser exactamente el mismo resultado si se aplican una o varias veces (no puede devolver un 404 si ya se eliminó, o 'no cambiar' si el cliente pone el mismo). Eso lleva a sistemas robustos y menos interdependencia de interpretaciones exactas de la semántica.

Los estándares WS- * realmente tratan principalmente de ejecutar RPC sobre SOAP / HTTP. Por lo tanto, todo el pensamiento que entró en CORBA y J2EE y sus predecesores se ha movido principalmente a hacer el mismo tipo de cosas en XML. Esto significa cosas como declaraciones de tipo y contratos de servicio, intercambio de metadatos, seguridad declarativa, etc. Todas esas cosas "empresariales" reales. Su uso excesivo, incluso en la empresa, francamente.

Las personas que crean una aplicación web de Internet como usted, seguramente estarían mejor usando una arquitectura RESTful. Casi cualquier plataforma puede consumirlo y hacerlo de manera simple y sin preocuparse de qué versión de qué especificación está utilizando y una miríada de peculiaridades de conversión de tipos específicos de herramientas, etc.

La única gran ventaja de SOAP sobre las implementaciones REST actuales es que SOAP se trabaja más fácilmente: la mayoría de los clientes RESTful requieren que comprenda la interfaz y escriba algún tipo de cliente. Para SOAP, solo apunto wsdl.exe y genera clases para mí.