rest here

Al principio era un poco escéptico sobre el uso de servicios REST en aplicaciones empresariales, sin embargo, creo que esta modalidad de servicios SOA se está imponiendo a los basados en SOAP (los de WS-*).

¿Por qué se provoca este cambio? a mi parecer, debido al empuje que están teniendo las aplicaciones web ricas, en las que toda la presentación y control de la vista se hace exclusivamente en el cliente y también, por supuesto, debido al auge de las aplicaciones móviles y todo lo que ello conlleva.

Claro que si lo miramos detenidamente, al final, ambos casos son el mismo. Tenemos una aplicación cliente que le pide servicios a una aplicación de servidor. Debido a que en un caso se ejecuta íntegramente en el navegador y otro en el propio dispositivo nunca ha estado tan claro el desacoplamiento entre el cliente y el productor del servicio. Así que por lo tanto, primeramente estamos en un “escenario de libro” en cuanto al uso de servicios… pero ¿Por qué en REST y no en SOAP?.

Creo que estas razones tienen algo que ver con esto:

  1. REST está orientado a objetos mientras SOAP está orientando a procedimientos
    En REST se trabaja con objetos (recursos) a los que se le asigna un identificador único y se interactua con las cuatro operaciones básicas (GET, PUT, POST y DELETE)
  2. REST es enormemente más sencilla y fácil de implemenar
    No hace falta generar proxies ni utilizar complejas librerías de transformación de XML
  3. Las APIS más usadas están hechas con REST: Google, Apple, Microsoft…

Por supuesto, REST no debe aplicarse a todos los casos. Por ejemplo su falta de un estándar de contrato verdaramente utilizado en las empresas puede desaconsejarlo para según que escenarios. Si tuviera que invocar a un servicio web de un banco desde mi empresa con todo tipo de seguridad (firma, certificados, no repudio, etc. etc.) usaría sin duda la pila de estándares de WS-*.

Así pues, nos toca incorporar servicios REST en nuestra empresa (si no lo hemos hecho ya), y no es un tema trivial. Si estamos acostumbrados a pensar en SOAP, tenemos que hacer un esfuerzo para pensar en REST y desaprender lo aprendido durante años.