Introduccion A Servicios Web

Introducción a los servicios web
[6.1] ¿Cómo estudiar este tema?
[6.2] Introducción a XML
[6.3] Arquitecturas orientadas a servicios (SOA): servicios web
[6.4] El protocolo SOAP
[6.5] El protocolo REST
6 TEMA
Esquema
Introducción a los servicios web
TEMA 6 – Esquema
Implementación en PHP de servicios web
Introducción a XML SOA El protocolo SOAP El protocolo REST
2
Características Definición de SOA Servicios web sin WSDL Características
Definición de servicio web

Servicios web con WSDL Diferencia con SOAP
Sintaxis
Ejemplo con generación de

DTD/XMLSchema WSDL
Uso de servicios web ajenos
© Universidad Internacional de La Rioja (UNIR)

Computación en el Servidor Web
Ideas clave
6.1. ¿Cómo estudiar este tema?
Para estudiar este tema lee las Ideas clave que encontrarás a continuación.
Además, tendrás que estudiar las siguientes páginas disponibles bajo licencia CEDRO:
» Welling, L. y Thomson, L. (2005). Desarrollo web con PHP y MySQL, capítulo 33

(páginas 876 a 880). Anaya Interactiva-Anaya Multimedia. en el apartado 6.2.
Introducción a XML.
En el primer apartado de este tema, aprenderemos nociones básicas de XML, con

objeto de que puedas entender suficientemente bien la información que se trata en los
servicios web.
Aprenderemos qué es SOA, una Arquitectura Orientada a Servicios. Verás que existen
diferentes definiciones, pero entenderás la idea rápidamente. También aprenderemos
qué son los servicios web.
Aprenderemos a implementar los servicios web en SOAP y accederemos a librerías

auxiliares que nos servirán para poder construir la información de nuestros servicios.
También aprenderemos las características de los servicios web RESTful, su utilidad

y las razones de su éxito.
Al final del tema hemos incluido más ejemplos, tanto de SOAP como de REST. Además
te dejamos información adicional sobre XML y otros temas relacionados, para que tengas
suficiente información para resolver tus dudas e inquietudes.
Así, al finalizar el tema, tendremos una visión general de los servicios web y tendremos
las herramientas necesarias para poder iniciarnos en la programación de este tipo de
aplicaciones.
TEMA 6 – Ideas clave 3 © Universidad Internacional de La Rioja (UNIR)

6.2. Introducción a XML
Los servicios web trabajan frecuentemente con XML, por lo que es importante conocer
cómo funciona este lenguaje. XML (eXtensible Markup Language) es un lenguaje de
marcado, al igual que HMTL, cuya finalidad no es mostrar datos, como HTML, sino
describirlos. Para hacerlo, utiliza etiquetas que se describen ad hoc para cada documento
(o tipo de documento). Estas etiquetas siguen unas reglas gramaticales similares a las
de HTML, de tal forma que tendremos etiquetas de apertura y cierre, los elementos
podrán anidarse y podremos darles atributos.
Sin embargo, la principal diferencia entre HTML y XML es que las etiquetas que
utilizamos no están definidas a priori, sino que se diseñan para cada
documento, lo que aporta una flexibilidad extraordinaria a este lenguaje.
Entonces, ¿cómo se puede compartir la información? ¿cómo entiende el destinatario el
contenido del fichero si no utilizamos etiquetas estándar? La respuesta es sencilla: junto
con el fichero que describe los datos, el XML, necesitamos enviar lo que se denomina una
DTD (Document Type Definition) o un esquema XML (XMLSchema), donde
describiremos las etiquetas utilizadas en el documento XML, así como sus atributos y las
relaciones entre las etiquetas.
En las páginas del libro que te hemos proporcionado en este tema en el apartado 6.1.
¿Cómo estudiar este tema? puedes ver un ejemplo de un fichero XML. Podrás
comprobar su sencillez de comprensión, ya que las etiquetas tienen una fuerte carga
semántica y podrás comprobar cómo sigue reglas de uso muy similares a HTML.
Además, al final del tema te dejamos una referencia para que puedas profundizar en el
uso de XML.
6.3. Arquitecturas orientadas a servicios (SOA): servicios web
Una arquitectura orientada a servicios (SOA, Service Oriented Architecture) es una

manera de organizar el software que facilita la extensibilidad de la funcionalidad y parte
de un diseño suficientemente abstracto que permite responder rápidamente a cambios
en los requerimientos de los usuarios y de la tecnología.

No obstante, a lo largo del tiempo, han surgido numerosas definiciones de qué es SOA,
aunque a modo de introducción, nos quedaremos con una: Según la W3C, es un conjunto
componentes que pueden ser invocados y cuyas interfaces se pueden publicar y
descubrir.
SOA está muy enfocada al negocio, de tal forma que trata de resolver necesidades
cambiantes de las empresas para que se adapten rápidamente a las necesidades del
mercado. Aunque ya ha habido intentos anteriores, la ventaja de SOA ha surgido por la
adopción de estándares, que ha permitido aumentar la interoperabilidad, muy necesaria
en un escenario donde las empresas trabajan de forma descentralizada y a nivel
internacional. Además, la tecnología ha ganado en seguridad y compatibilidad, por lo
que el proceso técnico se ha facilitado también.
Los actores básicos de SOA son tres:
1. Proveedores de servicios: quien ofrece un servicio, es decir, ofrece funciones que

otros pueden usar.
2. Consumidores de servicios: quien solicita el uso de un servicio disponible (en un
proveedor de servicios).
3. Intermediario: el ente que mantiene información sobre los servicios o funciones
disponibles y la forma de utilizarlos. Para que esto exista, los proveedores de servicios
envían la información de sus servicios y los consumidores de información acceden a
ellos para consultar los servicios disponibles, así como la forma en que tiene que
usarlos.
Intermediario de servicios
Descripción
del servicio
Encuentra Publica
Consumidor de servicios Interactúa Proveedor de servicios
Figura 1: Componentes básicos de SOA
Como vemos en la figura 1, el proveedor de servicios publica la información de sus

servicios en el intermediario de servicios, el cual almacena una descripción del servicio.
Cuando el consumidor de servicios necesita usar un servicio, consulta el intermediario

de servicios para obtener información de los servicios disponibles y de la forma en que

debe utilizarlos. Una vez que tiene esta información, ya puede interactuar con el
proveedor de servicios, que recibirá la petición del consumidor, realizará las operaciones
oportunas y devolverá la respuesta obtenida de la ejecución del servicio solicitado.
«Un servicio web es un sistema software diseñado para soportar la interacción

máquina a máquina sobre una red, es decir, son interfaces (APIs) que pueden ser
accedidas remotamente».
(García-Sánchez, 2011)
La principal ventaja que ofrecen los servicios web es que estas aplicaciones que
intercambian datos pueden estar implementadas en diferentes lenguajes de
programación y ejecutadas sobre cualquier plataforma. Así, un servicio es accesible por
medio de un protocolo estándar y puede ser invocado por medio de una interfaz bien
definida. De esta forma, se consigue la extensibilidad e interoperabilidad tan
demandada y evita la necesidad de reescribir las aplicaciones para poder comunicarse
con otros sistemas.
6.4. El protocolo SOAP
SOAP (Simple Object Access Protocol o protocolo sencillo de acceso a objetos) es un

protocolo estándar de acceso a servicios web basado en XML, que permite realizar
llamadas a operaciones remotas.
Para describir la interfaz de las operaciones disponibles en un servicio se utiliza WSDL

(Web Services Description Language), que no es más que un fichero XML que indica
el nombre de las operaciones disponibles en el servicio, los parámetros que recibe cada
una de las operaciones, así como el orden y el tipo de los mismos y el tipo de respuesta
que devolverá cada una de las operaciones.
En este sentido, PHP permite utilizar conexiones a servicios web con WSDL o sin
él, aunque si vamos a usar un WSDL necesitaremos generarlo con alguna herramienta
auxiliar, ya que PHP no lo genera automáticamente. No obstante, existen algunas
herramientas que nos permiten generarlo, como por ejemplo:
» NuSOAP: disponible en http://sourceforge.net/projects/nusoap/

» WSDLCreator: http://www.phpclasses.org/package/3509-PHP-Generate-WSDL-
from-PHP-classes-code.html
» WSDLDefinition: creado por David Giffin y disponible en la siguiente dirección
web https://github.com/digitick/php-wsdl-writer
Otra opción es escribirlo a mano pero, como veremos en el ejemplo siguiente, es un

trabajo arduo, ya que el fichero WSDL incluye mucha información semántica que
aumenta considerablemente la información a incluir.
Como hemos comentado anteriormente, los servicios web requieren un servidor y un

cliente, además de la información del intermediario. En este tema, por tanto, vamos a
aprender a crear servicios web y para que otros puedan consumirlos y también, a
consumir servicios web, ya sean nuestros o estén disponibles en otros servidores.
Empezaremos por crear un servicio web SOAP en PHP. Antes de nada, señalaremos
que cada servicio debe estar en un fichero .php independiente. Para crear el servicio,
necesitaremos utilizar la clase SoapServer, tal como veremos en el siguiente ejemplo, que
crea un servicio (miServicio) al que añade dos operaciones: sumar y restar. Guardaremos
el fichero con el nombre server1.php.
<?php
function sumar($val1,$val2){
return $val1+$val2;
}
function restar($val1,$val2){
return $val1-$val2;
}
$miServicio = new SoapServer(null, array('uri'=> "es.unir.matemat"));

$miServicio->addFunction("sumar");
$miServicio->addFunction("restar");
$miServicio->handle();
?>

Veamos lo que hace el código del ejemplo. Al principio, crea las dos funciones que serán
las operaciones de nuestro servicio. Como vemos, las funciones se crean de la forma
habitual, es decir, no es necesario hacer ninguna referencia al servicio web al que se van
a incorporar. A continuación, creamos un objeto de la clase SoapServer, que recibe dos
parámetros:
1. El fichero WSDL que describe el servicio, o null, si no disponemos de ese fichero.

En el caso de que no tengamos el fichero WSDL, es necesario indicar algún valor para
el URI en el siguiente parámetro. Además, el valor del URI debe ser el mismo en el
cliente y en el servidor.
2. Un array de opciones que incluye, entre otras, la versión de SOAP por defecto
(soap_version), la codificación interna de caracteres (enconding) y la URI que actúa.
Si se indica la URI del fichero WSDL en el argumento anterior, este es opcional.
Una vez que tenemos el servicio creado, para que esté disponible y pueda usarse, hay que
desplegarlo en el servidor (deploy). A efectos prácticos y, asumiendo que utilizamos
XAMPP, lo único que tendremos que hacer es colocar el fichero en el directorio htdocs.
En el otro extremo tendremos el cliente PHP que consumirá servicios web, que
necesitará saber su ubicación, ya que no tenemos el fichero WSDL que contiene esa
información. Supongamos que sabemos que la ubicación del servicio es
http://localhost:8080/ejemploWS1/server1.php. Entonces, nuestro cliente
(client1.php) quedaría de la siguiente forma:
<?php
$url="http://localhost:8080/ejemploWS1/server1.php";
$cliente = new SoapClient(null,

array('location'=>$url,'uri'=>"es.unir.matemat"));
$suma = $cliente->sumar(2,3);
print("La suma es ".$suma."<br>");
$resta = $cliente->restar(3,2);
print("La resta es ".$resta);
?>

Vemos que el código es sencillo. En la primera línea, hemos indicado la ubicación del
servicio al que queremos acceder. A continuación, hemos creado un cliente SOAP
utilizando la clase SoapClient, que tiene los mismos argumentos que la clase SoapServer,
con el mismo significado y restricciones. De nuevo, puesto que no tenemos WSDL del
servicio, hemos indicado el URI en el array del segundo argumento, además de la URL
del servicio. Si tenemos el fichero WSDL no es necesario porque la ubicación del servicio
está indicada en dicho fichero.
El siguiente paso, será utilizar las operaciones del servicio. De nuevo, al no tener
el fichero WSDL tendremos que conocer las operaciones por algún medio para saber que
existen. Así, en el ejemplo utilizamos las operaciones de sumar y restar, mostrando el
resultado obtenido al usuario.
Como hemos visto, la creación y uso de servicios web es relativamente sencilla. Por
supuesto, se puede complicar cuanto queramos pero, conceptualmente, es fácil de
manejar. Sin embargo, parece que el hecho de obviar el fichero WSDL no es una buena
solución, ya que obliga a tener que localizar manualmente los datos del servicio. Por eso,
a continuación vamos a ver cómo podemos crear un servicio generando su WSDL.
Lo primero que haremos será crear una clase que contenga las operaciones que
implementa nuestro servicio. Lo haremos de esta forma porque la librería que
utilizaremos para generar el WSDL requiere una clase como argumento.
Para que podamos comprender bien las diferencias entre el uso o no de un fichero WSDL,
implementaremos de nuevo el mismo ejemplo anterior, pero de esta segunda manera.
Vamos a crear el fichero classService2.php:
<?php
/**
* Clase para manejar el Servicio
*/
class ClassService{
/**
* Sumar
*
* @param int $val1 Primer argumento de la suma
* @param int $val2 Segundo argumento de la suma
* @return int Resultado de sumar los argumentos

*/
public function sumar($val1, $val2)
{
return $val1 + $val2;
}
/**
* Restar
*
* @param int $val1 Primer argumento de la resta
* @param int $val2 Segundo argumento de la resta
* @return int Resultado de restar los argumentos
*/
public function restar($val1, $val2)
{
return $val1 + $val2;
}
}
?>
A continuación, vamos a crear el fichero WSDL para nuestro servicio. Para hacerlo,
vamos a usar la librería implementada por djkaty
(https://katyscode.wordpress.com/2006/07/27/automatic-wsdl-generation-in-php-
5/), el WSDLGeneration, que genera la el fichero WSDL a partir de la clase y de los
comentarios que hemos incluido.
Esta información es importante, ya que la forma en que documentemos nuestro código

será determinante para que el WSDL sea realmente útil. Por eso, no olvides indicar los
parámetros de cada operación y el tipo de dato que devuelve, tal como hemos hecho en
el ejemplo.
Para generar el WSDL utilizamos el siguiente código:
<?php
//Incluimos las librerías de Katy
require_once("./katy/classes/WsdlDefinition.php");
require_once("./katy/classes/WsdlWriter.php");
//Declaramos un objeto de la clase WsdlDefinition

$def = new WsdlDefinition();
//Indicamos el nombre de la clase que define el servicio

$def->setDefinitionName("ClassService");
//Ubicación del fichero.php que contiene la clase

$def->setClassFileName("./ClassService.php");
//Nombre del fichero WSDL que vamos a crear

$def->setWsdlFileName("./ClassService.wsdl");
//Fijamos el NameSpace
$def->setNameSpace("http://csw.unir.net");
//Indicamos la ubicación donde estará el servicio

$def->setEndPoint("http://localhost:8080/ejemploWS2/server2.php");
//Creamos el objeto que escribe el fichero

$wsdl = new WsdlWriter($def);
//Escribimos
print $wsdl->classToWsdl();
?>
Es importante destacar que, una vez generado el WSDL del servicio, no hay que volver a
generarlo más, por lo que este código sólo lo utilizaremos una vez. En el enlace al blog de
Katy y en el propio código hemos incluido información para que puedas entender qué se
hace en cada paso.
Para que no tengas ningún problema al usar este WSDL, tienes que copiar el código
fuente de la página una vez ejecutado el script y pegarlo en un fichero con extensión wsdl.
Fíjate que el texto empiece en la primera columna de la primera fila, dará error si no está
así.
Como este servicio es sencillo, vamos a mostrar el archivo que se ha generado para que
podamos comprobar el aspecto de un fichero WSDL.

La primera imagen contiene la información general del servicio y de la operación para

sumar y la segunda imagen contiene la información de la operación para restar y el cierre
del envoltorio.
Accede al aula virtual para descargar las dos imágenes.
Fíjate en la estructura de las etiquetas y en los valores que contienen, que son los mismos
que hemos declarado en nuestro código y que hemos incluido en la documentación.
El siguiente paso será crear el fichero equivalente al server1.php anterior, que

llamaremos server2.php:
<?php
require_once('classService.php');
$miServicio2 = new SoapServer('classService.wsdl');
$miServicio2->setClass('ClassService');
$miServicio2->handle();
?>
Como podemos comprobar, ahora no tenemos que incluir las funciones al servicio, ya
que queda implícito al incluir la clase que hemos implementado. De esta forma, con el
método setClass hemos incorporado las dos operaciones: sumar y restar. Esta es la única
parte del código que es diferente, ya que se finaliza inicializando el servicio, tal como en
el ejemplo anterior.
Ya solo nos queda implementar un cliente que use este servicio web. De nuevo, tenemos
que destacar las diferencias de usar el fichero WSDL; ahora no tenemos que hacer una
búsqueda de las operaciones del servicio, sino que podemos consultarlos desde código.
Veamos un ejemplo (client2.php):
<html>
<head> Pruebas servicio con WSDL </head>
<body>
<?php
$client2 = new SoapClient ('EjemploWS.wsdl');

echo "Las operaciones que tiene el servicio son las siguientes: ";
echo "<p>";
var_dump($client2->__getFunctions());
echo "</p>";

// Aquí podemos usar las operaciones del servicio

$res=$client2->sumar(3, 2);
echo "El resultado de sumar 3+2 es:".$res;
$res=$client2->restar(3, 2);
echo "El resultado de restar 3-2 es:".$res;
?>
</body>
</html>
El código para probar nuestro servicio web es sencillo y similar al cliente anterior. Lo
único que hemos incluido es la operación que nos permite ver las operaciones del servicio
web. Sin embargo, lo que en código solo supone una línea, a efectos prácticos es muy
relevante ya que nos permite, desde el punto de vista del servidor, dar a conocer nuestros
servicios, las operaciones que tienen y cómo funcionan esas operaciones y desde el punto
de vista del cliente, nos permite localizar los servicios y ser capaces de usarlos de forma
sencilla.
En cualquier caso, no siempre tendremos que construir nuestros servicios, de hecho la

filosofía de este tipo de arquitectura es poder usar servicios disponibles de forma sencilla.
Por ello, vamos a aprender también a buscar servicios web disponibles que
podamos utilizar. Para hacerlo, solo tenemos que buscar web services seguido de la
funcionalidad requerida o, si se buscan para descubrir qué se puede encontrar, bastaría
con añadir examples a la búsqueda anterior. Es importante señalar que, normalmente,
los servicios web de las empresas son privados y por tanto, no estarán disponibles para
que los acceda cualquier usuario. Entre este tipo de servicio podemos encontrar, por
ejemplo, los servicios de recuperación de información de la BD de una empresa, la
información de usuarios, etc. Este tipo de servicios se ponen disposición de otros
departamentos de las empresas o de socios externos para que puedan acceder a los datos,
pero de forma controlada según los criterios de la empresa. Implementando la
funcionalidad de esta forma, solo necesitan dar la interfaz del servicio, para controlar el
acceso a su información, ya que este control está dentro del propio servicio.
Para poder usar un servicio web de otra persona, lo único que necesitas es crear el cliente
e incluir el WSDL correspondiente. En el siguiente ejemplo vamos a utilizar un servicio
web que devuelve el tipo de cambio entre dos monedas. Para localizarlo, solo hemos
tenido que ir a Google.com y buscar de la siguiente forma: web services examples. Del
resultado ofrecido, hemos seleccionado uno sencillo.

Cuando pinchamos en el enlace

(http://www.webservicex.net/ws/WSDetails.aspx?WSID=10), podemos revisar su
fichero WSDL y localizar las operaciones disponibles y los argumentos que necesitan. A
partir de esta información, hemos construido este ejemplo:
<?php
$client = new
SoapClient("http://www.webservicex.net/CurrencyConvertor.asmx?WSDL");
//Cambiar dólares a euros

$cambio=$client->ConversionRate("USD", "EUR");
?>
Para profundizar un poco más en la forma de comunicación del cliente con el servidor,
ya sea para un servicio local o para uno que hemos descubierto, vamos a mostrar un
ejemplo generado con la herramienta SoapUI
(http://www.soapui.org/downloads/soapui/open-source.html). Esta herramienta es
open source, por lo que puedes descargarla y probar tus desarrollos. A continuación,
vamos a mostrar la información de los ficheros de petición y respuesta para el
ejemplo anterior, generados con SoapUI.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:web="http://www.webserviceX.NET/">
<soapenv:Header/>
<soapenv:Body>
<web:ConversionRate>
<web:FromCurrency>EUR</web:FromCurrency>
<web:ToCurrency>USD</web:ToCurrency>
</web:ConversionRate>
</soapenv:Body>
</soapenv:Envelope>

En este ejemplo podemos ver el mensaje SOAP generado para solicitar el cambio de
moneda de euros (EUR) a dólares americanos (USD). Desde un punto de vista funcional,
parece que la única información relevante en ese largo mensaje son seis letras: EUR y
USD. Sin embargo, el resto de la información permite dotar de significado al mensaje y
mantener la interoperabilidad entre distintas tecnologías. En concreto, los mensajes
SOAP tienen la siguiente estructura:
» Envoltorio (envelope): es la información que rodea al mensaje y que lo identifica

como un mensaje SOAP. Este elemento es obligatorio.
» Cabecera (header): contiene meta-información relativa a la forma en que debe
procesarse el mensaje.
» Cuerpo (body): es la información propiamente dicha incluyendo, entre otra
información, el servicio al que se llama y los parámetros que se pasan para hacer. Este
elemento es obligatorio.
» Errores (fault): se puede incluir información de los errores que hayan ocurrido
durante el envío y procesado de la información.
Para finalizar el ejemplo, mostraremos también el código generado para la respuesta del
servicio web:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<ConversionRateResponse xmlns="http://www.webserviceX.NET/">
<ConversionRateResult>1.0945</ConversionRateResult>
</ConversionRateResponse>
</soap:Body>
</soap:Envelope>
Como vemos, la información para el usuario es, de nuevo, una parte muy pequeña del
mensaje: 1,0945. Sin embargo, el resto de la información del mensaje permite que
podamos trabajar de forma transparente entre distintas plataformas y lenguajes de
programación. De hecho, no sabemos en qué lenguaje puede estar implementado el
servicio web que estamos utilizando.

6.5. El protocolo REST
REST (REpresentational State Transfer) es un tipo de arquitectura cuya principal

característica, que lo diferencia de SOAP, por ejemplo, es que no tiene estado. Esto
significa que entre dos llamadas cualesquiera que se hagan a un servicio REST, este
servicio no recuerda nada; pierde los datos. Por otra parte, las aplicaciones desarrolladas
bajo esta arquitectura se denominan RESTful.
De esta forma, REST proporciona accesos independientes a los recursos. Esto tiene
ventajas e inconvenientes, como es habitual. La ventaja es que no necesita memoria para
almacenar información de estado, lo cual amplía significativamente el número de
peticiones que puede atender, la desventaja es que, si se requiere información de estado
o, en general, cualquier tipo de información, es necesario mandarla en cada petición.
REST tiene otras características que lo distinguen de otros tipos de arquitecturas. Por
ejemplo, REST utiliza los métodos HTTP, lo cual permite que un cliente HTTP pueda
interactuar con un servidor HTTP sin realizar ninguna configuración especial. Además,
esto permite hacer una asociación directa entre los métodos y las operaciones básicas de
manejo de datos (CRUD: Create, Read, Update, Delete), de la siguiente forma:
» Para insertar datos (Create) se utiliza POST.

» Para seleccionar datos (Read) utilizamos GET, que no cambia el estado del servidor.
» Para actualizar la información, utilizamos PUT.
» Para borrar elementos del servidor, utilizamos DELETE.
Una aplicación REST se compone de recursos, cada uno de los cuales se identifica
mediante una URI (Uniform Resource Identifier). Otra característica de los servicios web
REST es la forma en que utiliza las URI. Puesto que la URI de un servicio será la
forma de accederlo, éstas deben ser sencillas e intuitivas. Para conseguirlo, se utilizan
URI con formato de path, es decir, como si fuera una URL de Internet
(http://www.ejemplo.es/clientes?nombre=pepe).
Algunas recomendaciones para construir este tipo de identificadores proponen que todas
las letras sean en minúscula o que se eviten los espacios, poniendo en su lugar guiones o
guiones bajos. Como es habitual, esta identificación hace referencia al recurso, no al
estado del mismo, por lo que en peticiones diferente podremos obtener respuestas
diferentes.

Por otra parte, estos recursos pueden estar interconectados, por lo que la representación
de un estado puede incluir enlaces a unos recursos. Además, esta representación
podría realizarse en distintos lenguajes: XML, CSV (para datos sencillos) o JSON.
Para implementar un servicio web REST, por tanto, hay que traducir las URIs de los
recursos a llamadas a los scripts apropiados. La forma de hacerlo será identificar los
archivos y directorios y, a partir de ellos, lo demás serán identificadores de recursos. De
esta forma, una vez identificado el recurso, podemos obtener los parámetros y construir
una petición con la información obtenida.
En esta asignatura hemos aprendido el lenguaje de programación PHP. Sin embargo

PHP no implementa, aún, ninguna librería para trabajar con REST. En cualquier caso,
hay algunos ejemplos en Internet de cómo podría usarse, por lo que hemos incluido uno
al final del tema para que puedas familiarizarte con la forma de trabajar.
Pero, en la práctica, ¿cuáles son las diferencias entre REST y SOAP? En primer
lugar, hablaremos de la forma en que se realizan las peticiones. Como vimos en el
apartado anterior, una petición SOAP es un fichero XML con información semántica que
incluye los datos que queremos enviar al servidor. Sin embargo, las peticiones en REST
serán de la siguiente forma (utilizando el método GET):
http://www.ejemplo.com/operaciones/suma?val1=3&val2=2.
Si te fijas con detenimiento, verás que hemos escrito suma en lugar de sumar, tal como
hacíamos en la operación del servicio web en SOAP. No es un error, en REST es habitual
denominar los recursos con nombre en lugar de hacerlo con verbos.
Por otra parte, REST es un formato más ligero, consume menos recursos y es más fácil
de construir y adoptar. Además, hemos comentado que el servidor no tiene estado, por
lo que son los clientes lo que tienen que gestionar esta información. Y la información
semántica es más informal que en SOAP, está orientada al usuario, por lo que el uso de
los recursos puede presentar alguna dificultad al principio.

Referencias bibliográficas
García-Sánchez, P., López, M. A., Castillo, P. A., González, J., y García Arenas María I.
(2011). Web 2.0: Arquitectura Orientada a Servicios en Java. Revista de Experiencias
Docentes en Ingeniería de Computadores, vol. 1.

Lo + recomendado
No dejes de leer…
Crear un webservice básico con PHP y SOAP
Crear un webservice básico con PHP y SOAP [blog]
En el enlace que te proponemos puedes encontrar un ejemplo de creación de servicio

web SOAP utilizando la librería NuSOAP para la generación del fichero WSDL.
Accede al documento a través del aula virtual o desde la siguiente dirección:

http://donnierock.com/2013/01/17/crear-un-webservice-basico-con-php-y-soap/
Mi primer webservice en PHP (chispas)
Iglesias, J. (2011). Mi primer webservice en PHP (chispas). [blog]
En este enlace se introduce la forma de crear un servicio web genérico, que el autor ha
documentado en referencia a la gestión de usuarios, aunque podría servirte como
esqueleto para el desarrollo de cualquier otro servicio web. Lo más interesante de este
ejemplo es el uso de WSDL Generator para generar el fichero WSDL.

http://blog.osusnet.com/2011/03/17/mi-primer-webservice-en-php-chispas/
TEMA 6 – Lo + recomendado 19 © Universidad Internacional de La Rioja (UNIR)

No dejes de ver…
Una forma diferente de implementación
En el ejemplo que te proponemos se utiliza una forma distinta de organizar el código.

Pensamos que puede ser interesante que te familiarices con otras formas de trabajar y
veas otras posibilidades que, en algunos casos, te pueden ser más sencillas. Este vídeo
está en inglés, pero podrás entenderlo fácilmente, ya que el autor escribe el código a
medida que habla, por lo que no te resultará difícil entenderlo.
Puedes acceder al vídeo a través del aula virtual o desde el siguiente enlace:
https://www.youtube.com/watch?v=3fUR2mNKZpM&index=1&list=PL68AB27B3444
C7A99
TEMA 6 – Lo + recomendado 20 © Universidad Internacional de La Rioja (UNIR)

+ Información
A fondo
JSON tutorial
JSON es un lenguaje de intercambio de datos que es también habitual, como alternativa

a XML.
Accede al documento a través del aula virtual o desde las siguientes direcciones:
Fuente en inglés (w3schools):
http://www.w3schools.com/json/default.asp
Tutorial JSON en castellano:

https://geekytheory.com/json-i-que-es-y-para-que-sirve-json/
Ejemplo PHP de servicio RESTful
Posilio, I. (2013). Ejemplo PHP de servicio RESTful. [blog]
Como hemos comentado, no es habitual usar RESTful con PHP. No obstante, hay algunas
librería que se han desarrollado para que sea posible. Para que puedas ver el
funcionamiento de REST sobre PHP, te dejamos el siguiente enlace, que implementa
funcionalidad para gestionar usuarios en una base de datos.

1ª parte: http://programandolo.blogspot.com.es/2013/08/ejemplo-php-de-servicio-
restful-parte-1.html
2ª parte: http://programandolo.blogspot.com.es/2013/08/ejemplo-php-de-servicio-
restful-parte-2.html
TEMA 6 – + Información 21 © Universidad Internacional de La Rioja (UNIR)

Enlaces relacionados
Pear
Existen frameworks de trabajo para PHP. Uno de los más utilizados actualmente el Pear,
que contiene librerías para realizar distintas operaciones habituales y, todas ellas, son de
calidad. Esto ocurre porque tiene una comunidad activa que mantiene el código y
actualiza la información de la página constantemente.
Accede a la página web a través del aula virtual o desde la siguiente dirección:
http://pear.php.net/
SOAP
Toda la información relacionada con las clases SoapServer y SoapCliente, incluyendo sus
métodos y especificaciones, así como ejemplos de uso, la puedes encontrar en el web de
PHP en español, en concreto, en el enlace que te indicamos a continuación.
http://php.net/manual/es/book.soap.php

Introducción a XML
En la web puedes encontrar muchos manuales y tutoriales sobre XML. No obstante,

pensamos que este, de DesarrolloWeb, es adecuado para empezar con XML e ir
aprendiendo de forma sencilla y eficiente. Además, está ilustrado con ejemplos que te
servirán para entender mejor las explicaciones.
http://www.desarrolloweb.com/manuales/18/
Bibliografía
Mitchel, L. J. (2013). PHP Web Services. EEUU: O’Reilly Media, Inc.
Recursos externos
SoapUI
SoapUI es una herramienta open source que te permite ver el contenido de los mensajes
que se intercambian entre el cliente y el servidor, pudiendo hacer distintas pruebas de
forma muy intuitiva y viendo cómo se construyen los ficheros de solicitud y respuesta.
http://www.soapui.org/downloads/soapui/open-source.html

Test
1. La principal diferencia entre HTML y XML es:

A. Que HTML sirve para describir los datos y XML para mostrarlos.
B. Que HTML sirve para mostrar los datos y XML para describirlos.
C. Que XML anida los elementos de forma inteligente y no es tan estricto con las
etiquetas de cierre.
2. Que XML no tenga un conjunto de etiquetas estándar es:

A. Una ventaja, porque da flexibilidad.
B. Un inconveniente, porque requiere ficheros externos para describir el
significado.
C. Las dos anteriores son correctas.
3. Respecto a al DTD o el XMLSchema, podríamos decir que:

A. Serían el equivalente a la declaración de una clase, y el fichero XML sería una
instancia.
B. Serían como una librería que usa el fichero XML.
C. Ninguna de las dos son correctas.
4. En una arquitectura orientada a servicios, el intermediario:

A. Se encarga de establecer y mantener la conexión entre el cliente y el servidor.
B. Se encarga de actuar como repositorio de información, para que se puedan
consultar los servicios disponibles.
C. Se encarga de actuar como traductor entre el lenguaje que usa el cliente y el que
usa el servidor.
5. Los intermediarios en una arquitectura orientada a servicios:

A. Reciben la información de los servicios por parte del servidor y la ponen a
disposición de clientes que la soliciten.
B. Ofrecen información de los servicios a los clientes que la solicitan.
C. Las dos anteriores son correctas.
TEMA 6 – Test 24 © Universidad Internacional de La Rioja (UNIR)

6. Para utilizar un servicio web SOAP:

A. Es necesario conocer su interfaz.
B. Es necesario tener disponible el WSDL.
C. Es necesario que la clase implemente su interfaz.
7. Para usar SOAP con PHP:

A. Hay que descargar librerías que implementen SOAP.
B. Hay que descargar librerías que generen el WSDL.
C. Se usan las funciones SoapServer y SoapClient.
8. Cuando se implementa un servicio web SOAP sin WSDL:

A. Hay que poner la URI en el segundo parámetro del servidor.
B. Hay que poner la URL en el segundo parámetro del cliente.
C. Las dos son correctas.
9. Para poder utilizar un servicio web:

A. Tenemos que conocer su interfaz y localización, por lo que lo usual es obtener el
WSDL de dicho servicio.
B. Tenemos que implementarlo y desplegarlo en un servidor.
C. Las dos opciones son válidas.
10. La principal diferencia entre un servicio web SOAP y uno REST es:
A. Que REST no guarda información de estado.
B. Que SOAP no guarda información de estado.
C. Que pertenece a una arquitectura distinta.
TEMA 6 – Test 25 © Universidad Internacional de La Rioja (UNIR)

Introduccion A Servicios Web

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Introduccion A Servicios Web

Enviado por

Direitos autorais:

Formatos disponíveis

Introducción a los servicios web

[6.1] ¿Cómo estudiar este tema?

[6.2] Introducción a XML

[6.3] Arquitecturas orientadas a servicios (SOA): servicios web

[6.4] El protocolo SOAP

[6.5] El protocolo REST

Introducción a los servicios web

Introducción a XML SOA El protocolo SOAP El protocolo REST

Definición de servicio web

Ejemplo con generación de

Uso de servicios web ajenos

© Universidad Internacional de La Rioja (UNIR)

6.1. ¿Cómo estudiar este tema?

» Welling, L. y Thomson, L. (2005). Desarrollo web con PHP y MySQL, capítulo 33

En el primer apartado de este tema, aprenderemos nociones básicas de XML, con

Aprenderemos a implementar los servicios web en SOAP y accederemos a librerías

También aprenderemos las características de los servicios web RESTful, su utilidad

TEMA 6 – Ideas clave 3 © Universidad Internacional de La Rioja (UNIR)

6.2. Introducción a XML

6.3. Arquitecturas orientadas a servicios (SOA): servicios web

Una arquitectura orientada a servicios (SOA, Service Oriented Architecture) es una

TEMA 6 – Ideas clave 4 © Universidad Internacional de La Rioja (UNIR)

Los actores básicos de SOA son tres:

1. Proveedores de servicios: quien ofrece un servicio, es decir, ofrece funciones que

Consumidor de servicios Interactúa Proveedor de servicios

Figura 1: Componentes básicos de SOA

Como vemos en la figura 1, el proveedor de servicios publica la información de sus

TEMA 6 – Ideas clave 5 © Universidad Internacional de La Rioja (UNIR)

de servicios para obtener información de los servicios disponibles y de la forma en que

«Un servicio web es un sistema software diseñado para soportar la interacción

6.4. El protocolo SOAP

SOAP (Simple Object Access Protocol o protocolo sencillo de acceso a objetos) es un

Para describir la interfaz de las operaciones disponibles en un servicio se utiliza WSDL

» NuSOAP: disponible en http://sourceforge.net/projects/nusoap/

TEMA 6 – Ideas clave 6 © Universidad Internacional de La Rioja (UNIR)

Otra opción es escribirlo a mano pero, como veremos en el ejemplo siguiente, es un

Como hemos comentado anteriormente, los servicios web requieren un servidor y un

$miServicio = new SoapServer(null, array('uri'=> "es.unir.matemat"));

TEMA 6 – Ideas clave 7 © Universidad Internacional de La Rioja (UNIR)

1. El fichero WSDL que describe el servicio, o null, si no disponemos de ese fichero.

$cliente = new SoapClient(null,

TEMA 6 – Ideas clave 8 © Universidad Internacional de La Rioja (UNIR)

TEMA 6 – Ideas clave 9 © Universidad Internacional de La Rioja (UNIR)

Esta información es importante, ya que la forma en que documentemos nuestro código

Para generar el WSDL utilizamos el siguiente código:

//Declaramos un objeto de la clase WsdlDefinition

TEMA 6 – Ideas clave 10 © Universidad Internacional de La Rioja (UNIR)

$def = new WsdlDefinition();

//Indicamos el nombre de la clase que define el servicio

//Ubicación del fichero.php que contiene la clase

//Nombre del fichero WSDL que vamos a crear

//Indicamos la ubicación donde estará el servicio

//Creamos el objeto que escribe el fichero

TEMA 6 – Ideas clave 11 © Universidad Internacional de La Rioja (UNIR)

La primera imagen contiene la información general del servicio y de la operación para

Accede al aula virtual para descargar las dos imágenes.

El siguiente paso será crear el fichero equivalente al server1.php anterior, que

$client2 = new SoapClient ('EjemploWS.wsdl');

TEMA 6 – Ideas clave 12 © Universidad Internacional de La Rioja (UNIR)

// Aquí podemos usar las operaciones del servicio

En cualquier caso, no siempre tendremos que construir nuestros servicios, de hecho la

TEMA 6 – Ideas clave 13 © Universidad Internacional de La Rioja (UNIR)

Cuando pinchamos en el enlace