SOAP y el REST
SOAP es la abreviación para “Simple Object Access Protocol” y es el protocolo que se esconde tras la tecnología que usualmente se denomina “Web Services” o servicios web. SOAP es un protocolo realmente complicado, pensado para dar salidas a casi cualquier necesidad en lo que a comunicaciones trata, incluye también los aspectos desarrollados de seguridad, transaccionalidad, mensajería consolidada y demás. Cuando surgió SOAP se estuvo en una época dorada de los servicios web. Sin embargo, las primeras ejecuciones eran lo que se denominaban WS1.0 y no aguantaban casi ningún escenario moderno, todo el mundo pagaba el precio de utilizar SOAP, ya que se consideraba evidente que era el estándar que dominaría el futuro. Con el pasar del tiempo surgieron las descripciones WS-* que proporcionaban procedimientos avanzadas, pero a la vez que progresaban las capacidades de SOAP, progresaba su complicación. Al final, los servicios web SOAP acaban siendo un monstruo con diversas capacidades pero que en la totalidad de los casos no se necesitan.
Por otro lado, REST es sencillo. REST no pretende dar soluciones para todo y por lo tanto no se paga con una demasiada complejidad y una fuerza que quizá no vayan a requerir.
Uniform interface
Una discrepancia el cual es esencial entre un servicio web clásico (SOAP) y un servicio REST es que el inicial está encaminado a RPC, o sea, a invocar sistemáticas sobre un servicio remoto, mientras que el secundario está enfocado a recursos. O sea, se opera sobre recursos, no sobre servicios.
En una API REST la idea de “servicio” como tal desaparece. Lo que se tienen son recursos, asequibles por identificadores (URIs). Sobre esos capitales se pueden hacer acciones, ordinariamente características por medio de verbos HTTP diferentes.
Así, en un servicio web clásico (SOAP) se poseería un servicio llamado BeerService que asumiría un método llamado GetAll el cual devolvería todas las bebidas. La idea, soberanamente de la tecnología manejada para ingerir el servicio web, es que se llama a una técnica (GetAll) de un servicio remoto (BeerService). De la misma forma para conseguir una bebida determinada, llamaríamos a la técnica GetById pasándole el id de la bebida. De allí que se diga que están encaminados a RPC (Remote Procedure Call – Llamada a método remoto).
Y mirando su otra parte con respecto al servicio REST, la propia idea de servicio se disipa. En lugar de ello queda la idea de un “recurso”, en este caso le ponemos “Colección de bebidas” que posee una URI que lo asemeja, por ejemplo; /Drinks. Así que, si llamo dicha URI se debe lograr una representación de dicho recurso, o sea, se debe lograr el listado de todas las bebidas.
Para conseguir los datos de una bebida, habrá otro recurso (soda) con una URI coligada. Igualmente, entre los recursos hay relaciones: Es obvio que una soda forma parte de la “Colección de bebidas” así que parece lógico que a partir de la colección entera (/Drinks) se pueda entrar a uno de sus elementos con una URI tipo /Drinks/321, siendo “321” el ID de la soda.
Ahora bien, con respecto al servicio SOAP: Para dar de alta una bebida habría que llamar a un método “AddDrink” de vuestro “DrinkService”, y le transitaríamos la bebida a incluir. En cambio, en vuestra API REST ampliar una bebida reside en utilizar la URI de dicha bebida, (por ejemplo /Drinks/654 si se está incluyendo la bebida con ID 654) manejando POST o PUT como verbo HTTP y poniendo los datos de la bebida en el cuerpo de la petición. La URI para entrar a la bebida con ID 654 es siempre /Drinks/654 y es el verbo HTTP (GET, POST, PUT, DELETE,…) es el que muestra cual es la maniobra que se desea realizar con esa bebida.
