UNIVERSIDAD DOMINGO
SAVIO
PROGRAMACION WEB Il
API REST vs API SOAP
CARRERA: Ingeniería de Sistemas
DOCENTE: Ingeniera Marlene Monica Suntura
ESTUDIANTE: Ascencio Chura Juan Carlos
Una descripción de REST
REST ofrece una alternativa más ligera. Muchos desarrolladores encontraron
SOAP engorroso y difícil de usar. Por ejemplo, trabajar con SOAP en
JavaScript significa escribir una tonelada de código para realizar tareas simples
porque debe crear la estructura XML requerida cada vez.
En lugar de usar XML para realizar una solicitud, REST (generalmente) se basa
en una URL simple. En algunas situaciones, debe proporcionar información
adicional, pero la mayoría de los servicios web que utilizan REST se basan
exclusivamente en el método de URL. REST puede usar cuatro verbos HTTP
1.1 diferentes (GET, POST, PUT y DELETE) para realizar tareas.
A diferencia de SOAP, REST no tiene que usar XML para proporcionar la
respuesta. Puede encontrar servicios web basados en REST que generan los
datos en valores separados por comandos (CSV), notación de objetos
JavaScript (JSON) y distribución realmente simple (RSS). El punto es que
puede obtener la salida que necesita, en una forma que sea fácil de analizar
dentro del idioma que está usando para su aplicación
Una descripción general rápida de SOAP
SOAP se basa exclusivamente en XML para proporcionar servicios de
mensajería. Microsoft desarrolló originalmente SOAP para reemplazar las
tecnologías más antiguas que no funcionan bien en Internet, como el Modelo
de objetos componentes distribuidos (DCOM) y la Arquitectura de agente de
solicitud de objetos comunes (CORBA). Estas tecnologías fallan porque
dependen de la mensajería binaria. La mensajería XML que emplea SOAP
funciona mejor a través de Internet.
Después de una versión inicial, Microsoft presentó SOAP al Grupo de trabajo
de ingeniería de Internet (IETF), donde se estandarizó. SOAP está diseñado
para admitir la expansión, por lo que tiene todo tipo de acrónimos y
abreviaturas asociadas, como WS-Addressing, WS-Policy, WS-Security, WS-
Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction
y WS-RemotePortlets. De hecho, puede encontrar una lista completa de estos
estándares en Estándares de servicios web.
El punto es que SOAP es altamente extensible, pero solo usa las piezas que
necesita para una tarea en particular. Por ejemplo, cuando utiliza un servicio
web público que está disponible gratuitamente para todos, realmente no tiene
mucha necesidad de WS-Security.
La dificultad depende del lenguaje de programación
El XML utilizado para realizar solicitudes y recibir respuestas en SOAP puede
volverse extremadamente complejo. En algunos lenguajes de programación,
debe generar esas solicitudes manualmente, lo que se vuelve problemático
porque SOAP no tolera los errores. Sin embargo, otros lenguajes pueden
utilizar los accesos directos que proporciona SOAP. Pueden ayudarlo a reducir
el esfuerzo requerido para crear la solicitud y analizar la respuesta. De hecho,
cuando trabaja con lenguajes .NET, ni siquiera ve el XML.
Parte de la magia es el lenguaje de descripción de servicios web (WSDL). Este
es otro archivo que está asociado con SOAP. Proporciona una definición de
cómo funciona el servicio web, de modo que cuando crea una referencia a él, el
IDE puede automatizar completamente el proceso. Entonces, la dificultad de
usar SOAP depende en gran medida del idioma que use.
Manejo de errores integrado
Una de las características de SOAP más importantes es el manejo de errores
integrado. Si hay un problema con su solicitud, la respuesta contiene
información de error que puede utilizar para solucionar el problema. Dado que
es posible que no sea propietario del servicio web, esta característica en
particular es extremadamente importante; de lo contrario, se quedaría
adivinando por qué las cosas no funcionaron. El informe de errores incluso
proporciona códigos estandarizados para que sea posible automatizar algunas
tareas de manejo de errores en su código.
Una característica interesante de SOAP es que no necesariamente tiene que
usarlo con el transporte HTTP. Existe una especificación real para usar SOAP
sobre el Protocolo simple de transferencia de correo (SMTP) y no hay ninguna
razón por la que no pueda usarlo en otros transportes. De hecho, los
desarrolladores de algunos lenguajes, como Python y PHP, están haciendo
precisamente eso .
SOAP y REST
A menos que planee crear su propio servicio web, es posible que ya haya
tomado la decisión de qué protocolo usar. Muy pocos servicios web, como
Amazon, admiten ambos. El enfoque de su decisión a menudo se centra en
qué servicio web se adapta mejor a sus necesidades, en lugar de qué
protocolo utilizar.
Ventajas de Soap
SOAP ofrece las siguientes ventajas en comparación con REST:
• Independiente del idioma, la plataforma y el transporte (REST requiere el
uso de HTTP)
• Funciona bien en entornos empresariales distribuidos (REST asume una
comunicación directa punto a punto)
• Estandarizado
• Proporciona importantes Extensibilidad preconstruida en forma de
estándares WS *
• Manejo de errores incorporado
• Automatización cuando se usa con ciertos productos de lenguaje
Ventajas de REST
REST es más fácil de usar en su mayor parte y es más flexible. Tiene las
siguientes ventajas sobre SOAP:
• No se requieren herramientas costosas para interactuar con el servicio web
• Curva de aprendizaje más pequeña
• Eficiente (SOAP usa XML para todos los mensajes, REST puede usar
formatos de mensaje más pequeños)
• Rápido (no requiere un procesamiento extenso)
• Más cercano a otras tecnologías web en la filosofía del diseño
Un ejemplo simple de REST
A veces, lo simple es lo mejor. En este caso, REST es tan simple como parece
porque todo lo que necesita es una URL. Abra su navegador, no importa cuál, y
escriba http://rpc.geocoder.us/service/csv?address=1600+Pennsylvania+Ave,
+Washington+DC en el campo de dirección. Presione Entrar.
Verá la salida en su navegador en formato CSV:
Verá la latitud, seguida de la longitud, seguida de la dirección que
proporcionó. Esta sencilla prueba funciona para la mayoría de las direcciones
en la mayoría de las ciudades importantes (todavía no funciona muy bien para
las direcciones rurales). La idea es que obtenga la latitud y longitud necesarias
para su uso con otros servicios web. Combinando servicios web junto con un
pequeño código adhesivo, puede crear aplicaciones realmente interesantes
que hacen cosas increíbles en poco tiempo y con poco esfuerzo. Todos los
demás están haciendo el trabajo pesado. También puede probar su API
REST con herramientas fáciles de usar como SoapUI.
Un ejemplo simple de SOAP
SOAP, por su propia naturaleza, requiere un poco más de configuración, pero
sigue siendo impresionantemente fácil de usar.
Comience este ejemplo creando una aplicación de Windows Forms con Visual
Studio . El código de muestra usa C #, pero la misma técnica funciona bien con
otros lenguajes .NET ( deberá modificar el código para que se ajuste ). Agregue
etiquetas, cuadros de texto y botones como se muestra aquí ( los campos
Latitud y Longitud son de solo lectura ).
Aquí es donde entra en juego la automatización. Haga clic con el botón
derecho en Referencias en el Explorador de soluciones y elija Agregar
referencia de servicio en el menú contextual. Verá el cuadro de diálogo Agregar
referencia de servicio. Escriba la siguiente dirección en el campo de dirección:
http://rpc.geocoder.us/dist/eg/clients/GeoCoder.wsdl y haga clic en Ir . Escriba
GeocoderService en el campo del espacio de nombres. Su cuadro de diálogo
debería verse como el que se muestra aquí.
Haga clic en Aceptar . Visual Studio agrega el código necesario para trabajar
con Geocoder en segundo plano.
En este punto, está listo para usar el servicio web. Todo lo que necesita hacer
es agregar código al botón Obtener posición como se muestra aquí.
private void btnGetPosition_Click (remitente del objeto, EventArgs e)
// Crea el cliente.
GeocoderService.GeoCode_PortTypeClient Client =
nuevo GeocoderService.GeoCode_PortTypeClient ();
// Haz la llamada.
GeocoderService.GeocoderResult [] Resultado =
Client.geocode (txtAddress.Text);
// Compruebe si hay un resultado de error.
si (Resultado! = nulo)
{
// Muestra los resultados en pantalla.
txtLatitude.Text = Resultado [0] .lat.ToString ();
txtLongitude.Text = Resultado [0]. @ long.ToString ();
}
demás
{
// Muestra un resultado de error.
txtLatitude.Text = "Error";
txtLongitude.Text = "Error";
}
