\section{Servicios Web, WSDL 2.0}
+Los servicios web definen un mecanismo para la interacción entre máquinas usando la red y XML\footnote{\emph{Extensible Markup Language} o Lenguaje de Marcado Extensible, ver: \url{http://www.w3.org/XML/}}. Un componente clave de un servicio Web es una descripción formal con \emph{Web Services Description Language}, es decir, el Lenguaje de Descripción de Servicios Web o WSDL por sus siglas en Inglés. Hasta no hace muchos años (en concreto, hasta el año 2007) no existía un lenguaje formal para la descripción de \emph{REpresentational State Transfer (REST) Web services}. Pero desde la aparición del WSDL 2.0\footnote{\emph{WSDL 2.0}, ver: \url{http://www.w3.org/TR/wsdl20/}} sí es posible~\cite{C5:IBMREST}.
+El término \emph{Web services} está típicamente asociado con operaciones o acciones basadas en servicios usando SAOP\footnote{\emph{Simple Object Access Protocol} o Protocolo Simple de Acceso a Objetos, ver: \url{http://www.w3.org/TR/soap/}} y los estándares WS*, tales como \emph{WS-Addressing} y \emph{WS-Security}. El término \emph{REST WEB services} generalmente se refiere a una arquitectura de servicios Web basada en recursos que usa HTTP y XML. Los estilos de arquitecturas SAOP y REST son usados ampliamente, pero tuvieron que pasar muchos años hasta que el estándar WSDL soportó de igual forma ambos. El \emph{binding}\footnote{\emph{Binding WSDL 2.0}, ver: \url{http://www.w3.org/TR/wsdl20/\#Binding}} del WSDL 1.1 HTTP era inadecuado para describir comunicaciones con HTTP Y XML, por tanto no había modo para formalmente describir servicios Web REST con WSDL. La publicación del WSDL 2.0, el cual fue diseñado con los servicios Web REST en mente, como una recomendación del \emph{World Wide Web Consortium} o W3C, significa que a partir de ese momento existe un lenguaje para describir servicios Web REST.
+
+\subsection{REST}
+
+\emph{REST} es un estilo de arquitectura que trata la Web como una aplicación centrada en recursos. De forma práctica, esto significa que cada URL en una aplicación RESTful representa un recurso. Las URLs son también fáciles de entender y recordar. Por ejemplo, una tienda de venta de libros puede definir la URL http://www.bookstore.com/books/ para una lista de libros que esa tienda vende y la URL http://www.bookstore.com/books/0321396/ para obtener detalles acerca de un libro determinado en función de su número ISBN. Esto es un claro contraste a las aplicaciones centradas en acciones, las cuales típicamente tienen largas y crípticas URLs describiendo acciones para realizar, tales como, http://www.bookstore.com/action/query?t=b\&id=111114532\&qp=0321396. Los parámetros de la query son usados para filtrar los resultados.
+
+El doctor Roy Fielding acuñó el término REST en su doctorado, donde él se refirió a el lenguaje HTTP y sus \emph{hyperlinks}\footnote{Sobre hyperlinks, ver: \url{http://en.wikipedia.org/wiki/Hyperlink}} como el motor de las aplicaciones basadas en estado. Esto significa que se espera que un recurso contenga \emph{hyperlinks}. Estos \emph{hyperlinks} son el método por el cual puede tomar lugar una transición que transfiere o cambia el estado de un recurso. Servicios Web REST hacen uso de \emph{hyperlinks}.
+
+Aplicaciones Web tradicionales acceden a recursos usando operaciones HTTP GET o POST. En contraste, aplicaciones RESTful acceden a recursos siguiendo el estilo \emph{create}, \emph{read}, \emph{update} y \emph{delete} o CRUD por sus siglas en Inglés; y usan el rango completo de verbos HTTP (POST, GET, PUT y DELETE).
+
+Hay otro componente clave relacionado con las aplicaciones REST: las aplicaciones RESTful no deberían tener estado. Esto significa que en una aplicación REST no se almacena el estado de la sesión en el servidor. Toda la información necesaria para satisfacer la petición es transportada en el mismo mensaje de petición.
+
+\subsubsection{Retornando otros tipos de contenidos}
+
+Los servicios Web generalmente devuelven datos como XML pero hay otros tipos de contenidos que son muy prácticos para los consumidores de servicios. Por ejemplo, en aplicaciones Ajax\footnote{\emph{Asynchronous JavaScript + XML}} suele ser preferible recibir datos del tipo JSON (\emph{JavaScript Object Notation}), por otro lado si el consumidor no es una máquina si no una persona que debe interpretar directamente los datos, probablemente quiera recibir estos datos como HTML, el cual puede ser fácilmente renderizado en el navegador Web. En el mundo HTTP, la selección del formato de los datos es conocida como \emph{content type negotiation}. En un \emph{content type negotiation}, el cliente especifica el tipo de contenido que prefiere y el que es aceptable, luego el servicio responde con el más apropiado tipo de contenido. Esto significa que un cliente puede pedir los datos desde un servicio Web como XML, y otro cliente puede pedir a ese mismo servicio Web los datos como JSON o algún otro tipo como puede ser YAML\footnote{Sobre YAML, ver: \url{http://www.yaml.org/}}.
+
+Para dar a los clientes la capacidad para pedir un determinado tipo de contenido, se deben construir los servicios para que hagan uso de la cabecera HTTP \emph{Content-Type: text/html}. Una alternativa para aplicaciones que no entienden la cabecera \emph{Content-Type} es especificar un parámetro en la propia URL que represente el tipo de dato: xml, json, yaml, etc.
+
+\subsection{WSDL y REST}
+
+Una descripción WSDL contiene todos los detalles de un servicio Web, incluyendo:
+
+\begin{itemize}
+ \item La URL del servicio.
+ \item El mecanismo de comunicación que el servicio entiende.
+ \item Las operaciones que puede realizar.
+ \item La estructura de sus mensajes.
+\end{itemize}
+
+Los clientes pueden usar estos detalles para interactuar con un servicio.
+
+El \emph{binding} en WSDL 1.1 era inadecuado para describir servicios Web REST. WSDL 2.0 fue declarado como una recomendación del W3C (\emph{World Wide Consortium}) en Junio del 2007. La segunda versión de WSDL fue precisamente creada para direccionar los problemas con WSDL 1.0, muchos de los cuales habían ya sido identificados por la organización WS-I (\emph{Web Services Interoperability}). Además WSDL 2.0 tiene buen soporte para generar HTTP bindings que son los que los servicios Web REST necesitan.
+
+WSDL es un lenguaje XML para formalmente describir un servicio Web. Se puede considerar la descripción mediante WSDL de un servicio Web como el contrato entre este servicio Web y los clientes que deben usarlo. La descripción WSDL especifica la dirección, los mecanismos de comunicación permitidos, el interfaz y los tipos de mensajes de un servicio Web. En resumen, una descripción WSDL proporciona toda la información que un cliente necesita para usar un servicio Web.
year = {2000},
keywords = "entity, relationship, model",
}
+
+@Article{C5:IBMREST,
+ author = {{Lawrence Mandel}},
+ title = {Describe REST Web services with WSDL 2.0.},
+ howpublished = "Website",
+ note = {\url{http://www.ibm.com/developerworks/webservices/library/ws-restwsdl/}},
+ publisher = {IBM},
+ year = {2008},
+ keywords = "IBM, REST, SOAP, Web, services",
+}
projects / PFCLatex / .git / commitdiff