En la empresa BK Programación, María ha estado trabajando en el diseño de una aplicación web. A medida que profundiza sus conocimientos en el lenguaje PHP, descubre que tiene más herramientas a su disposición para mejorar la programación de la aplicación.
Una preocupación clave en el desarrollo del proyecto es la capacidad de reutilizar partes del código en el futuro. Por ejemplo, si se desarrolla una función para consultar el inventario de un producto específico en diferentes tiendas, sería beneficioso poder utilizar esa función no solo en la aplicación web actual, sino también en cualquier otra aplicación que pueda requerir dicha información.
María discute sus inquietudes con Lucía, y juntos deciden tomarse un tiempo para evaluar las diferentes opciones para abordar este desafío. Aunque esto podría retrasar el proyecto temporalmente, esperan obtener una aplicación más versátil y accesible como resultado. Al considerar soluciones como servicios web y APIs, buscan facilitar el acceso y la reutilización de la información en múltiples plataformas cuando sea necesario.
Los servicios web son aplicaciones que facilitan la comunicación entre diferentes sistemas y arquitecturas empleando protocolos estándar como HTTP y XML o JSON. Permiten integrar sistemas y automatizar tareas independientemente del lenguaje de programación o plataforma.
En esta unidad, se comenzará definiendo los servicios web y sus fundamentos. Posteriormente, se abordarán los dos protocolos más populares en el ámbito de servicios web, SOAP y REST, destacando sus características y diferencias. Finalmente, se proporcionarán ejemplos prácticos de implementación de servicios web en PHP y Laravel, incluyendo la creación de servidores y clientes SOAP y REST, así como aplicaciones específicas como una calculadora y un gestor de tareas.
HTTP (Protocolo de Transferencia de Hipertexto) es un protocolo de comunicación utilizado en la World Wide Web para el intercambio de información entre un servidor y un cliente. Permite la solicitud y transferencia de datos, como páginas web, de manera segura y eficiente.
XML (Extensible Markup Language) es un lenguaje de marcado utilizado para estructurar datos de forma legible por humanos y máquinas. Permite definir etiquetas personalizadas y organizar la información jerárquicamente, facilitando el intercambio de datos entre diferentes sistemas y plataformas.
JSON (JavaScript Object Notation) es un formato de intercambio de datos ligero y legible por humanos. Se basa en la sintaxis de objetos y listas de JavaScript, y se utiliza ampliamente en aplicaciones web y servicios web para transmitir y almacenar información estructurada de manera eficiente.
SOAP (Simple Object Access Protocol) es un protocolo de comunicación basado en XML que permite intercambiar mensajes entre aplicaciones web. Utiliza HTTP como transporte y define un conjunto de reglas para la estructura y formato de los mensajes, facilitando la interoperabilidad entre diferentes sistemas y tecnologías.
REST (Representational State Transfer) es un estilo arquitectónico para el diseño de servicios web que se basa en el uso de los métodos HTTP (GET, POST, PUT, DELETE) y recursos identificados por URLs. Promueve la simplicidad, escalabilidad y la interoperabilidad entre sistemas distribuidos.
Laravel es un 'framework' web de desarrollo de aplicaciones web en PHP. Proporciona una estructura robusta y elegante para crear aplicaciones modernas, con características como enrutamiento, manejo de bases de datos, autenticación y muchas otras utilidades para agilizar el desarrollo y mejorar la productividad del desarrollador.
En la empresa CreatiCode, Juan y Pedro están colaborando en el desarrollo de un sistema de gestión de proyectos. A medida que avanzan en su trabajo, se dan cuenta de la importancia de comunicarse eficientemente con otros sistemas y servicios para mejorar la experiencia del usuario.
Un desafío clave en el desarrollo del proyecto es la necesidad de intercambiar información con aplicaciones de terceros. Por ejemplo, si se desea integrar las tareas de un proyecto con un calendario externo, sería ventajoso contar con una solución que facilite el flujo de datos entre ambos sistemas, independientemente del lenguaje de programación o la plataforma utilizada.
Juan y Pedro abordan el tema en una reunión con su equipo y, después de investigar y analizar varias opciones, deciden que la implementación de servicios web es la solución más adecuada para su proyecto. Los servicios web permitirán una comunicación fluida y segura entre la aplicación de gestión de proyectos y otras aplicaciones, promoviendo la interoperabilidad y la reutilización de funciones.
Con esta decisión, se embarcan en la tarea de diseñar e implementar servicios web y APIs que faciliten el intercambio de información entre sistemas, mejorando así la eficiencia y la experiencia del usuario en su sistema de gestión de proyectos.
Los servicios web representan una solución tecnológica que permite la interacción entre sistemas y aplicaciones en entornos heterogéneos y distribuidos. Al estar basados en estándares y protocolos ampliamente aceptados, como HTTP, XML y JSON, los servicios web garantizan un alto grado de compatibilidad y accesibilidad para las aplicaciones que los consumen.
En la era actual de la transformación digital, las organizaciones requieren cada vez más soluciones de software que se integren sin problemas con sistemas existentes y permitan el flujo eficiente de información. Los servicios web juegan un papel crucial en la creación de arquitecturas flexibles y modulares que facilitan la comunicación entre aplicaciones y sistemas desarrollados con diferentes tecnologías y en distintas plataformas.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
Un servicio web es una tecnología que posibilita la comunicación e intercambio de datos entre diferentes sistemas y aplicaciones a través de Internet. Su principal objetivo es facilitar la interacción y colaboración entre distintas plataformas, lenguajes de programación y arquitecturas, lo cual resulta esencial en el ámbito de las Tecnologías de la Información y Comunicación (TIC).
La esencia de un servicio web radica en su capacidad para proporcionar funcionalidades específicas mediante un conjunto de protocolos y estándares universalmente aceptados y utilizados. Estos elementos garantizan la compatibilidad con una amplia gama de sistemas y aplicaciones, al tiempo que permiten a los desarrolladores diseñar e implementar servicios web de manera eficiente y organizada.
Los servicios web mayormente se basan en una arquitectura cliente-servidor, donde el cliente realiza peticiones a un servidor que proporciona las funcionalidades requeridas. Estas peticiones y respuestas se comunican a través de mensajes estructurados, generalmente en formatos como XML o JSON. Los servicios web ofrecen ventajas como la abstracción de la lógica de negocio, permitiendo a los desarrolladores centrarse en la funcionalidad y el diseño de las aplicaciones.
Para garantizar la correcta comunicación entre los diferentes componentes involucrados, los servicios web se apoyan en protocolos de transporte, como el Protocolo de Transferencia de Hipertexto (HTTP). Estos protocolos son responsables de transmitir los mensajes entre el cliente y el servidor de manera segura y confiable.
Algunos servicios web emplean mecanismos de descubrimiento y publicación para facilitar la localización y utilización de sus funcionalidades. Un ejemplo de ello es el Universal Description, Discovery, and Integration (UDDI), un estándar que permite a las empresas registrar y buscar servicios web disponibles en un directorio centralizado.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
Si estás interesado en profundizar tu conocimiento sobre los servicios web, es recomendable explorar una amplia variedad de recursos disponibles en línea que pueden ser de gran ayuda. Para empezar, puedes visitar la página de Wikipedia en inglés sobre Servicios Web. Esta página ofrece una introducción sólida al tema, definiendo lo que son los servicios web y explicando cómo funcionan.
Los servicios web ofrecen numerosos beneficios y propósitos en el desarrollo de software y la arquitectura de sistemas. Entre los principales se encuentran:
Christopher Gower. Un portátil con líneas de código(Licencia Unsplash)Interoperabilidad: los servicios web permiten la comunicación entre aplicaciones y sistemas desarrollados en diferentes lenguajes de programación y plataformas, lo que facilita la integración y colaboración entre sistemas heterogéneos. La interoperabilidad permite a las organizaciones y desarrolladores superar las barreras tecnológicas y aprovechar al máximo los recursos disponibles.
Reutilización: al exponer funcionalidades y datos a través de servicios web, las organizaciones y desarrolladores pueden compartir y reutilizar componentes, lo que puede llevar a una mayor eficiencia y reducción de costos en el desarrollo y mantenimiento de software. La reutilización de componentes también promueve las prácticas de desarrollo ágil y mejora la calidad y coherencia del software.
Escalabilidad: los servicios web permiten la creación de arquitecturas distribuidas y escalables, lo que puede mejorar el rendimiento y la capacidad de respuesta de las aplicaciones y sistemas. La escalabilidad es esencial para satisfacer las demandas cambiantes de los usuarios y mantener un alto nivel de disponibilidad y rendimiento en entornos empresariales y comerciales.
Desacoplamiento: al utilizar servicios web para separar y encapsular funcionalidades y datos, se pueden desarrollar sistemas más flexibles y modulares, lo que facilita la evolución y el mantenimiento del software. El desacoplamiento también permite a las organizaciones y desarrolladores abordar y actualizar componentes individuales de un sistema sin afectar negativamente a otros componentes o al sistema en su conjunto.
Seguridad: los servicios web pueden implementar medidas de seguridad para proteger la información y las transacciones que se transmiten entre aplicaciones y sistemas. Al utilizar protocolos y estándares de seguridad, como Transport Layer Security (TLS), los servicios web pueden garantizar la confidencialidad, integridad y autenticación de los datos.
Mantenibilidad: la modularidad y desacoplamiento proporcionados por los servicios web facilitan la actualización, mejora y mantenimiento de aplicaciones y sistemas a lo largo del tiempo. Los desarrolladores pueden modificar o reemplazar componentes individuales sin afectar a otros componentes o a la funcionalidad general del sistema, lo que permite una mayor flexibilidad y agilidad en el desarrollo de software.
¿Cómo los servicios web, en el contexto de tu propia experiencia o en un proyecto en el que hayas trabajado o estés trabajando, pueden mejorar la eficiencia, escalabilidad, y la mantenibilidad de tu proyecto? ¿Cómo podrían implementarse los servicios web en ese contexto para maximizar estos beneficios?
La respuesta es verdadero. Los servicios web ofrecen interoperabilidad, lo que significa que permiten la comunicación entre aplicaciones y sistemas desarrollados en diferentes lenguajes de programación y plataformas. Esto se logra a través del uso de estándares y protocolos basados en web, como HTTP, XML y JSON, entre otros. Estos estándares permiten que las aplicaciones se comuniquen y compartan datos de manera efectiva, incluso si están escritas en diferentes lenguajes de programación o se ejecutan en diferentes sistemas operativos. La interoperabilidad facilita la integración y colaboración entre sistemas heterogéneos, lo que a su vez permite a las organizaciones y desarrolladores superar las barreras tecnológicas y aprovechar al máximo los recursos disponibles.
Los servicios web son soluciones que permiten la comunicación e interacción entre diferentes sistemas y aplicaciones a través de Internet. Existen diferentes tipos de servicios web siendo los dos más comunes SOAP y REST. A continuación, se describen brevemente estos tipos de servicios web y algunos otros que también son relevantes en el ámbito de las tecnologías de la información.
SOAP (Simple Object Access Protocol): es un protocolo de comunicación basado en XML que se utiliza para intercambiar información estructurada en la implementación de servicios web. Es un estándar desarrollado por el World Wide Web Consortium (W3C) y se basa en la arquitectura de servicios web orientada a servicios (SOA). SOAP utiliza el protocolo HTTP como transporte, aunque también puede utilizar otros protocolos como SMTP o JMS.
REST(Representational State Transfer): es un estilo de arquitectura de software que define un conjunto de restricciones y principios a seguir para crear servicios web escalables y de fácil mantenimiento. A diferencia de SOAP, REST no es un protocolo, sino un conjunto de principios de diseño. Los servicios web RESTful utilizan los métodos estándar HTTP (GET, POST, PUT y DELETE) para realizar operaciones en los recursos, y estos recursos se identifican mediante URI (Uniform Resource Identifier). El formato de intercambio de datos en REST puede ser XML, JSON u otros formatos.
Shahadat Rahman. Código en PHP(Licencia Unsplash)XML-RPC(XML Remote Procedure Call): es un protocolo de llamada a procedimiento remoto (RPC) que utiliza XML para codificar sus llamadas, mientras que el protocolo de transporte subyacente es HTTP. Aunque es menos conocido que SOAP y REST, XML-RPC es un protocolo más simple y fácil de usar. Sin embargo, debido a su simplicidad, carece de algunas características que están presentes en SOAP, como la seguridad y la capacidad de manejar mensajes complejos.
JSON-RPC y JSON-WSP(JSON Remote Procedure Call y JSON Web Service Protocol): son protocolos de llamada a procedimiento remoto que utilizan JSON en lugar de XML para codificar sus llamadas. Al igual que XML-RPC, estos protocolos también utilizan HTTP como protocolo de transporte. JSON-RPC y JSON-WSP son más ligeros y rápidos que SOAP y XML-RPC debido a la simplicidad y menor verbosidad de JSON en comparación con XML.
gRPC: es un moderno protocolo de llamada a procedimientos remotos (RPC) desarrollado por Google. Utiliza el formato de serialización binaria Protocol Buffers en lugar de XML o JSON, lo que lo hace más rápido y eficiente en la transmisión de datos. gRPC es especialmente adecuado para aplicaciones de baja latencia y alto rendimiento, como la comunicación entre microservicios. Además, gRPC es compatible con múltiples lenguajes de programación y es transportado sobre HTTP/2, lo que permite aprovechar las características avanzadas de este protocolo, como la multiplexación y la compresión de encabezados.
WebSockets: son una tecnología que permite establecer una comunicación bidireccional y en tiempo real entre un navegador y un servidor a través de una conexión TCP persistente. A diferencia de las peticiones HTTP típicas, que son unidireccionales y sin estado, los WebSockets mantienen una conexión abierta, permitiendo el envío y recepción de mensajes en tiempo real sin la necesidad de realizar múltiples solicitudes y respuestas. Los WebSockets son ideales para aplicaciones en tiempo real, como juegos en línea, chats y aplicaciones de colaboración en vivo.
GraphQL: es un lenguaje de consulta y un tiempo de ejecución para APIs desarrollado por Facebook. A diferencia de los servicios web RESTful, donde cada recurso tiene una URL y se utiliza un conjunto fijo de métodos HTTP, GraphQL permite a los clientes especificar exactamente qué datos necesitan y cómo deben ser entregados. GraphQL utiliza un único punto final (endpoint) para todas las consultas y mutaciones, lo que simplifica la gestión de la API. Además, GraphQL admite la agregación de datos de múltiples fuentes y sistemas en una única respuesta, lo que puede mejorar la eficiencia y el rendimiento en aplicaciones con múltiples servicios interdependientes.
OData (Open Data Protocol): es un protocolo de comunicación abierto que se basa en tecnologías web estándar como HTTP, AtomPub y JSON para proporcionar acceso a datos estructurados a través de servicios web. OData permite a los clientes realizar consultas y manipular datos utilizando operaciones CRUD (Crear, Leer, Actualizar y Eliminar) y admite funciones avanzadas como la paginación, el filtrado y la ordenación. El protocolo OData es compatible con una amplia gama de lenguajes de programación y plataformas, lo que facilita la integración de sistemas y la creación de aplicaciones que consumen datos de múltiples fuentes.
SMTP (Simple Mail Transfer Protocol) es un protocolo estándar de Internet utilizado para el envío de correos electrónicos. Se encarga de la transferencia de mensajes de correo entre servidores y define las reglas y formatos necesarios para la entrega exitosa de los correos electrónicos.
JMS (Java Message Service) es una API de Java para la creación, envío y recepción de mensajes entre aplicaciones. Permite la comunicación asíncrona y fiable mediante la utilización de colas y temas, facilitando la integración y la interoperabilidad entre diferentes sistemas distribuidos.
W3C (World Wide Web Consortium) es una organización internacional que desarrolla estándares y pautas para la web. Su objetivo es asegurar la interoperabilidad y el crecimiento sostenible de la World Wide Web, promoviendo tecnologías abiertas y accesibles para todos los usuarios.
SOA (Service-Oriented Architecture) es un enfoque arquitectónico para el diseño de sistemas de software basado en servicios independientes y reutilizables. Los servicios se comunican a través de interfaces estándar, permitiendo la integración y colaboración entre diferentes aplicaciones y plataformas de manera flexible y escalable.
HTTP GET es un método de solicitud utilizado en el protocolo HTTP. Se utiliza para recuperar recursos o información de un servidor web especificado por una URL, enviando una solicitud al servidor y obteniendo una respuesta que contiene los datos solicitados.
HTTP POST es un método de solicitud utilizado en el protocolo HTTP. Se utiliza para enviar datos al servidor web especificado por una URL, enviando la información en el cuerpo de la solicitud. Es comúnmente utilizado para enviar datos de formularios o para realizar operaciones que modifican el estado del servidor.
HTTP PUT es un método de solicitud utilizado en el protocolo HTTP. Se utiliza para enviar datos al servidor web para crear o reemplazar el recurso identificado por una URL específica. Permite actualizar completamente un recurso existente o crear uno nuevo en la ubicación indicada.
HTTP DELETE es un método de solicitud utilizado en el protocolo HTTP. Se utiliza para solicitar al servidor web que elimine el recurso identificado por una URL específica. El servidor procesa la solicitud y elimina el recurso correspondiente, devolviendo una respuesta indicando el éxito o fracaso de la operación.
URI (Uniform Resource Identifier) es una cadena de caracteres que identifica un recurso en la web de manera única. Consiste en una combinación de URL (Uniform Resource Locator) y URN (Uniform Resource Name) para localizar o nombrar recursos como páginas web, archivos, servicios, entre otros.
API (Application Programming Interface) es un conjunto de reglas y protocolos que permiten la interacción entre diferentes aplicaciones y servicios. Proporciona una interfaz que define cómo los componentes de software pueden comunicarse y utilizar funcionalidades específicas de otros sistemas de manera estandarizada.
RPC (Remote Procedure Call) es un mecanismo de comunicación entre procesos que permite invocar funciones o procedimientos en un sistema remoto como si fueran llamadas locales. Facilita la integración y la interacción entre diferentes sistemas distribuidos, simplificando el desarrollo de aplicaciones distribuidas.
TCP (Transmission Control Protocol) es un protocolo de comunicación confiable y orientado a conexión utilizado en Internet. Proporciona una entrega ordenada y sin errores de datos entre aplicaciones a través de la segmentación, el control de flujo y la confirmación de recepción de paquetes.
HTTP/2 es una versión actualizada del protocolo HTTP que mejora la eficiencia y rendimiento de las comunicaciones web. Utiliza multiplexación, compresión de cabeceras y otros mecanismos para permitir una transferencia más rápida de datos y optimizar la experiencia de usuario en aplicaciones web.
AtomPub (Atom Publishing Protocol) es un protocolo basado en el estándar Atom para la edición y publicación de contenidos web. Permite la creación, modificación y eliminación de entradas, proporcionando un enfoque uniforme y estándar para la gestión de contenido en aplicaciones y servicios web.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
En Wikipedia existen otras tres entradas que podrían interesarte si buscas una comprensión más profunda de los servicios web: List of web service protocols (proporciona una lista de los protocolos utilizados en los servicios web) y List of web service specifications (proporciona una lista de las especificaciones utilizadas en los servicios web) y List of web service frameworks (proporciona una lista de los marcos de trabajo o frameworks que se pueden utilizar para construir servicios web).
En la empresa TechGrid, un proveedor de soluciones tecnológicas para empresas de logística, Laura y Marta están trabajando en un proyecto para mejorar la coordinación y comunicación entre los distintos sistemas de información utilizados por sus clientes. Para ello, quieren integrar los sistemas de información de sus clientes con los sistemas de información de sus proveedores de servicios de transporte.
Laura y Marta identifican que la solución a este desafío es implementar SOAP (Simple Object Access Protocol), un protocolo que permite la comunicación entre aplicaciones a través de redes, independientemente del lenguaje de programación o la plataforma utilizada. Las características de SOAP incluyen su capacidad para manejar comunicaciones complejas y su compatibilidad con cualquier protocolo de transporte, como HTTP, SMTP, entre otros, lo que lo convierte en una opción flexible y poderosa.
Además, Laura y Marta deciden utilizar WSDL (Web Services Description Language) para describir los servicios web ofrecidos. Este lenguaje proporciona detalles sobre las operaciones disponibles, los mensajes utilizados, los puntos de enlace del servicio y la información sobre el protocolo y formato de datos.
SOAP es un protocolo basado en XML que permite la comunicación e intercambio de información entre aplicaciones a través de redes, utilizando principalmente el protocolo HTTP. Este protocolo fue diseñado para ser extensible, neutral en cuanto a la plataforma y el lenguaje de programación, y permitir la comunicación entre aplicaciones independientemente de su arquitectura interna.
Inicialmente, SOAP fue concebido como XML-RPC en junio de 1998. A lo largo del tiempo, el protocolo evolucionó y pasó a llamarse Simple Object Access Protocol (SOAP) en su versión 1.1, publicada el 8 de mayo de 2000. Posteriormente, se desarrolló la versión 1.2 del protocolo, que fue aprobada como Recomendación W3C el 27 de abril de 2007.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
SOAP (Simple Object Access Protocol) es un protocolo de comunicación estándar que permite a los diferentes sistemas informáticos interactuar y compartir información a través de la web. Este protocolo se basa en XML para codificar y transportar los mensajes entre los sistemas, y utiliza principalmente HTTP como protocolo de transporte, aunque también admite otros protocolos.
SOAP presenta tres características principales que lo hacen adecuado para su uso en servicios web:
Extensibilidad: SOAP permite la incorporación de nuevas funcionalidades a través de extensiones, como seguridad y WS-Addressing, que define un espacio de nombres para identificar servicios web.
Neutralidad: SOAP puede operar sobre cualquier protocolo de transporte, como HTTP, SMTP, TCP o UDP, lo que facilita su adaptación a diferentes contextos y aplicaciones.
Independencia: SOAP permite utilizar cualquier modelo de programación, lo que facilita su implementación en diversos lenguajes y entornos.
La arquitectura de servicios web, según el W3C Working Group Note del 11 de febrero de 2004, describe la interacción entre servicios web.
Según dicha arquitectura, el proveedor del servicio (service provider) envía un archivo WSDL (Web Services Description Language) al registro UDDI (Universal Description, Discovery, and Integration). Cuando un solicitante de servicio (service requester) necesita una funcionalidad específica, consulta el registro UDDI para encontrar el proveedor del servicio correspondiente. Una vez que ha encontrado el proveedor adecuado, el solicitante de servicio se comunica con el proveedor de servicio utilizando el protocolo SOAP. Luego, el proveedor del servicio verifica la solicitud y, si es válida, envía datos estructurados en un archivo XML, también utilizando SOAP. El archivo XML contiene la información requerida y puede incluir datos de respuesta o posibles errores que puedan ocurrir durante el proceso.
Entre las ventajas que ofrece SOAP se encuentran las siguientes:
Estándar y amplia adopción: SOAP se basa en estándares ampliamente aceptados y ha sido implementado durante muchos años en la industria.
Integración con cortafuegos y proxies existentes: SOAP se integra fácilmente con infraestructuras de comunicación existentes, evitando la necesidad de modificarlas.
Aprovecha las facilidades de XML: SOAP utiliza XML, lo que permite su fácil internacionalización y extensibilidad mediante Namespaces.
Sin embargo, SOAP también tiene desventajas como se indican a continuación:
Rendimiento afectado por la serialización XML: la serialización XML en SOAP puede afectar el rendimiento debido a la verbosidad del protocolo.
Limitaciones en la flexibilidad de los roles: En SOAP, los roles de las partes involucradas en la comunicación están fijos, lo que puede limitar la flexibilidad en ciertos escenarios.
Limitaciones en comparación con REST: la popularidad de REST ha disminuido la adopción de SOAP debido a que SOAP no puede aprovechar las características específicas del protocolo HTTP, como la interfaz uniforme de REST. Además, SOAP puede requerir la reimplementación de funciones proporcionadas por protocolos complementarios.
WS-Addressing (Web Services Addressing) es una especificación que proporciona un modelo estándar para la comunicación de mensajes en servicios web. Permite la identificación y enrutamiento de mensajes a través de la inclusión de direcciones y metadatos en los encabezados SOAP, facilitando la interoperabilidad entre diferentes servicios.
Un cortafuegos o 'firewall' es una barrera de seguridad que controla y filtra el tráfico de red entre una red privada y externa. Su función es proteger los sistemas informáticos al bloquear conexiones no autorizadas y prevenir ataques y accesos no deseados desde Internet.
Un 'proxy' es un intermediario que actúa en nombre de un cliente para acceder a recursos de otros servidores. Actúa como un punto de contacto entre el cliente y el servidor, permitiendo el enrutamiento, el filtrado y el cacheo de las solicitudes y respuestas para mejorar la velocidad y la seguridad de la comunicación.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
Para un entendimiento completo y detallado del protocolo SOAP, es fundamental que consultes la especificación SOAP 1.2, recomendación oficial del World Wide Web Consortium (W3C) desde el 27 de abril de 2007. Este recurso, accesible en el sitio web del W3C, te proporcionará información precisa sobre la estructura y procesamiento de los mensajes SOAP, patrones de intercambio, y cómo se unen a diversos protocolos de transporte, lo cual es esencial para su correcta implementación en cualquier proyecto de desarrollo de software.
Un mensaje SOAP es un documento XML que sigue una estructura específica y está compuesto por varios elementos clave para garantizar una comunicación efectiva entre aplicaciones. La estructura básica de un mensaje SOAP se compone de las siguientes partes:
Amy Hirschi. Escritorio con un ordenador(Licencia Unsplash)Envelope: el elemento Envelope es el contenedor principal y obligatorio de un mensaje SOAP. Envuelve todo el mensaje y define el espacio de nombres XML para identificar el documento como un mensaje SOAP válido. Este elemento contiene dos subelementos principales: Header y Body.
Header: el elemento Header es un subelemento opcional dentro del Envelope y puede contener información adicional que se requiera para el procesamiento del mensaje. Por ejemplo, datos de autenticación, trazabilidad o información específica del servicio web. Si el Header no es necesario para un mensaje específico, simplemente se omite.
Body: el elemento Body es un subelemento obligatorio dentro del Envelope y contiene la información principal del mensaje SOAP, como la solicitud o respuesta de una operación específica. Aquí se incluyen los detalles de la llamada a un método remoto, los parámetros y los valores de retorno.
Fault: el elemento Fault es un subelemento opcional que se puede incluir dentro del Body en caso de que se produzca un error durante el procesamiento del mensaje. Este elemento proporciona información detallada sobre el error, incluyendo un código de error, una descripción del error y posibles soluciones.
A continuación se muestra un ejemplo de un mensaje de solicitud y respuesta SOAP para obtener el precio del libro "Cien años de soledad" de Gabriel García Márquez.
La solicitud SOAP sería la siguiente:
POST /Libros HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope/" soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
<soap:Body xmlns:m="http://www.example.org/libro">
<m:GetBookPrice>
<m:BookName>Cien años de soledad</m:BookName>
</m:GetBookPrice>
</soap:Body>
</soap:Envelope>
En el ejemplo, la solicitud SOAP se envía al servidor utilizando el método POST del protocolo HTTP. La solicitud incluye la función GetBookPrice, que tiene un parámetro BookName. En este caso, BookName contiene el valor "Cien años de soledad". El espacio de nombres se define en "http://www.example.org/libro". La solicitud incluye la URL, el tipo de contenido y la longitud del contenido en la cabecera. Luego, el servidor recibe la solicitud y procesa la función GetBookPrice para buscar el precio del libro especificado. Luego, envía una respuesta SOAP que contiene la función GetBookPriceResponse y el parámetro Price con el valor correspondiente al precio del libro (en este ejemplo, 19.95). La respuesta incluye el código de estado HTTP 200, que indica que la solicitud se procesó con éxito.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
El Web Services Description Language (WSDL) es un lenguaje basado en XML utilizado para describir la funcionalidad ofrecida por un servicio web. WSDL permite a los desarrolladores entender cómo interactuar con un servicio web al proporcionar detalles sobre los métodos y parámetros disponibles. El propósito principal de WSDL es facilitar la comunicación entre diferentes sistemas al estandarizar la descripción de la interfaz de un servicio web.
La última versión de WSDL, que se convirtió en una recomendación de W3C en 2007, es WSDL 2.0. Al permitir la vinculación a todos los métodos de solicitud HTTP (no solo GET y POST como en la versión 1.1), la especificación WSDL 2.0 ofrece un mejor soporte para servicios web como RESTful y, además, es mucho más sencilla de implementar.
En WSDL 2.0, se definen diferentes términos para describir la estructura y funcionalidad de un servicio web:
Service: es una colección de puntos finales (endpoints) que ofrecen funcionalidades específicas. El elemento service en WSDL 2.0 agrupa todos los endpoints relacionados con un servicio web particular.
Endpoint: es una combinación de una dirección de red y una especificación de enlace (binding). La dirección de red, también conocida como dirección del servicio web, es una URL que permite a los clientes acceder al servicio web. El enlace describe cómo los mensajes deben ser formateados y enviados a través de la dirección de red.
Binding: especifica el protocolo y formato de datos que se utilizarán para interactuar con el servicio web. En WSDL 2.0, los bindings pueden ser específicos de SOAP, HTTP, o cualquier otro protocolo. El binding también define cómo se mapean las operaciones y mensajes a las solicitudes y respuestas HTTP.
Interface: describe las operaciones disponibles y los mensajes asociados a un servicio web. Las interfaces son fundamentales para la descripción de un servicio web, ya que definen cómo los clientes deben interactuar con él. Las interfaces en WSDL 2.0 son independientes del protocolo, lo que permite a los desarrolladores describir un servicio web sin preocuparse por los detalles de implementación.
Operation: es una acción específica que el servicio web puede realizar. Las operaciones en WSDL 2.0 consisten en una entrada (input), una salida (output) y, opcionalmente, mensajes de error (fault). Las operaciones pueden ser síncronas, donde el cliente espera una respuesta, o asíncronas, donde el cliente no espera una respuesta inmediata.
Types: los tipos definen los formatos de datos utilizados en los mensajes de entrada y salida de las operaciones. WSDL 2.0 utiliza XML Schema para describir la estructura y restricciones de los datos en los mensajes. Los tipos son fundamentales para garantizar la interoperabilidad entre los sistemas, ya que permiten a los clientes y proveedores de servicios web comunicarse utilizando un formato de datos común.
Un ejemplo sencillo de WSDL 2.0 podría ser un servicio web que convierte grados Celsius a Fahrenheit:
Este WSDL 2.0 define un servicio web llamado "TemperaturaService" con una única operación "CelsiusToFahrenheit". La operación toma como entrada un valor de temperatura en grados Celsius y devuelve el valor correspondiente en grados Fahrenheit. El servicio se expone a través de un enlace SOAP 1.2 utilizando el protocolo HTTP.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
Para entender profundamente WSDL, es esencial consultar las especificaciones oficiales. La especificación WSDL 2.0 ha sido una recomendación oficial del World Wide Web Consortium (W3C) desde el 26 de junio de 2007. Por otro lado, el documento de la W3C para WSDL 1.1, aunque no sea una recomendación oficial y se considere como una Nota W3C (15 de marzo de 2001), sigue siendo un recurso informativo de gran importancia. Estos dos documentos son fundamentales para aquellos que buscan un conocimiento integral de los servicios web basados en WSDL y SOAP.
UDDI (Universal Description, Discovery and Integration) es un estándar de directorio de servicios que permite a las empresas registrar y buscar servicios web disponibles en la red. UDDI fue desarrollado por un consorcio de empresas, incluyendo IBM, Microsoft y Ariba, con el objetivo de proporcionar un mecanismo estándar para describir, publicar y descubrir servicios web.
El propósito principal del UDDI es facilitar la interoperabilidad entre las aplicaciones de distintos proveedores y simplificar la integración de servicios web. Para lograr esto, UDDI proporciona un conjunto de especificaciones técnicas que describen cómo los servicios web pueden ser registrados, actualizados y descubiertos. Estas especificaciones incluyen información sobre los servicios, la dirección de los mismos, los protocolos de comunicación soportados y otros detalles técnicos.
Los registros UDDI se utilizan para almacenar y categorizar información sobre empresas y sus servicios web. Los componentes de la información registrada en un UDDI se dividen en tres categorías: White Pages, Yellow Pages y Green Pages.
White Pages (Páginas Blancas): contienen información básica de contacto sobre una empresa o negocio, similar a la información que se encuentra en una guía telefónica. Esto incluye el nombre de la empresa, dirección, información de contacto como teléfono y correo electrónico, y una breve descripción del negocio. Las White Pages ayudan a los usuarios a encontrar y comunicarse con una empresa específica.
Yellow Pages (Páginas Amarillas): proporcionan información sobre la categorización y clasificación de la empresa en términos de industria, productos y servicios ofrecidos. Esta información se organiza utilizando códigos estandarizados y taxonomías industriales, como el Sistema de Clasificación de la Industria de América del Norte (NAICS) o la Clasificación Estándar Industrial (SIC). Las Yellow Pages facilitan la búsqueda de empresas que ofrecen ciertos productos o servicios dentro de una industria o categoría específica.
Green Pages (Páginas Verdes): contienen información técnica sobre los servicios web que ofrece una empresa. Esto incluye detalles como las especificaciones de la interfaz de servicios (WSDL), los protocolos de comunicación y transporte (como HTTP, HTTPS, etc.), y la ubicación de los puntos finales del servicio. Las Green Pages permiten a los desarrolladores de aplicaciones descubrir y comprender cómo interactuar e integrarse con los servicios web de una empresa.
El modelo de datos UDDI, basado en el esquema XML (XSD), establece la forma en que se organiza y guarda la información de empresas y sus servicios web en un registro UDDI. Este modelo se compone de elementos clave como BusinessEntity, BusinessService, BindingTemplate y TModel, que juntos representan las Páginas Blancas, Páginas Amarillas y Páginas Verdes del registro UDDI. Estas entidades facilitan el descubrimiento y acceso a los servicios web, permiten clasificarlos por categorías y ayudan a entender cómo integrarlos en aplicaciones propias.
La información contenida en el UDDI es accesible mediante APIs de consulta que permiten a los clientes buscar y recuperar detalles de los servicios web disponibles. Estas consultas se pueden realizar de diferentes maneras, como por ejemplo, a través del uso de palabras clave, criterios de búsqueda específicos o incluso por categorías de servicios.
Un aspecto importante a considerar es que el UDDI no define cómo se deben invocar los servicios web. En su lugar, proporciona información suficiente para que los clientes puedan descubrir y seleccionar los servicios web adecuados y generar los clientes necesarios para invocar estos servicios. Esto significa que el UDDI es compatible con diferentes protocolos y estándares de servicios web, como SOAP y REST.
En la actualidad, aunque UDDI sigue siendo una herramienta útil para la publicación y descubrimiento de servicios web, su uso esinfrecuente debido al surgimiento de otras tecnologías y enfoques en la integración de sistemas. Sin embargo, comprender su funcionamiento junto con otros estándares como SOAP y WSDL es importante para así tener una comprensión completa de cómo se han desarrollado los servicios web.
Las APIs de consulta son interfaces de programación que permiten a los desarrolladores enviar consultas a un sistema o servicio y recibir respuestas estructuradas con datos específicos. Estas APIs brindan acceso a información actualizada y permiten la integración de datos externos en aplicaciones y sistemas.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
HTTPS (Hypertext Transfer Protocol Secure) es una versión segura de HTTP que utiliza criptografía para proteger la comunicación entre clientes y servidores en internet. Proporciona autenticación, integridad y confidencialidad de los datos, asegurando la privacidad y seguridad de la información transmitida.
En la empresa StreamLine, Carlos y Laura están desarrollando una aplicación móvil para gestionar las operaciones logísticas de una red de almacenes. A medida que avanzan en el proyecto, se percatan de la necesidad de un sistema que permita la comunicación eficiente y efectiva entre la aplicación móvil y el servidor de la base de datos, así como la posibilidad de escalar y expandir el sistema en el futuro.
Carlos y Laura identifican que REST (Representational State Transfer) es la solución ideal para su desafío. REST es un estilo de arquitectura de software que define un conjunto de restricciones para crear servicios web. Entre las características más importantes de REST se encuentran su estado sin conexión, que permite que cada solicitud del cliente al servidor sea independiente de las demás, y su interfaz uniforme, que simplifica y desacopla la arquitectura, permitiendo a cada parte evolucionar de forma independiente.
Finalmente, deciden implementar una HTTP RESTful API. Esto significa que utilizarán el protocolo HTTP para enviar y recibir mensajes entre la aplicación móvil y el servidor. Esta API permitirá operaciones como GET, POST, PUT, DELETE y otras para interactuar con los recursos del servidor. Esta decisión permitirá una integración más fluida con otras aplicaciones y plataformas.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
En el mundo de los servicios web, REST (Representational State Transfer) es un estilo arquitectónico ampliamente utilizado para el diseño de sistemas distribuidos. Se basa en un conjunto de principios que promueven una forma específica de comunicación entre los componentes de un sistema. REST fue desarrollado por Roy Fielding en su tesis doctoral en el 2000 y se ha vuelto muy popular debido a su simplicidad, flexibilidad y escalabilidad.
El concepto de REST (Representational State Transfer) fue introducido por Roy Thomas Fielding en 2000 a través de su tesis doctoral "Architectural Styles and the Design of Network-based Software Architectures" (Estilos arquitectónicos y el diseño de arquitecturas de software basadas en redes). Esta obra, escrita en inglés, es esencial para entender los fundamentos de REST y cómo se aplica al diseño de arquitecturas de software web.
REST (Representational State Transfer) es un estilo de arquitectura de software para sistemas distribuidos que se basa en la comunicación entre componentes mediante la transferencia de representaciones de recursos a través de protocolos estandarizados y sin estado. Desde un enfoque más técnico, REST es un conjunto de restricciones arquitectónicas que, cuando se aplican, resultan en un diseño de sistema escalable, sencillo y fácil de mantener.
Entre las características de REST se encuentran las siguientes:
Protocolo de transporte independiente: REST puede utilizarse con cualquier protocolo de transporte, aunque se utiliza comúnmente con HTTP debido a su amplia adopción y facilidad de uso.
Operaciones estandarizadas: cuando se emplea junto con HTTP, REST utiliza métodos de solicitud estandarizados, como GET, POST, PUT y DELETE, para realizar operaciones en los recursos.
Interfaz sencilla y uniforme: REST simplifica la comunicación al ofrecer una interfaz sencilla y coherente entre los servicios web, lo que facilita su comprensión e implementación.
Escalabilidad: gracias a su enfoque sin estado y al uso de caché, REST permite crear sistemas altamente escalables que pueden manejar grandes cantidades de tráfico y crecer con las necesidades del negocio.
Desacoplamiento: en REST, el cliente y el servidor funcionan de manera independiente, lo que permite evolucionar cada uno de ellos sin afectar al otro.
Entre sus ventajas, destaca su simplicidad, escalabilidad y facilidad de implementación, permitiendo a los desarrolladores crear aplicaciones de manera rápida y eficiente. Además, gracias a su naturaleza stateless, REST mejora la escalabilidad y el rendimiento al no almacenar información del estado del cliente en el servidor. Por otro lado, entre las desventajas de REST se incluyen la limitación a un conjunto reducido de métodos HTTP, lo que puede conducir a soluciones menos flexibles y a un uso subóptimo de los recursos. Además, en situaciones donde se requiere una comunicación en tiempo real, la arquitectura REST no es la opción ideal, ya que carece de soporte para WebSocket y que requiere encuestas periódicas para mantener la sincronización entre cliente y servidor.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
Los principios de diseño de REST son fundamentales para comprender y aplicar este estilo arquitectónico en la creación y consumo de servicios web. A continuación, se describen los seis principios clave que rigen el diseño de REST:
Comunicación cliente-servidor: este principio establece una separación clara entre el cliente y el servidor, lo que favorece la independencia y la portabilidad de cada componente. El cliente se encarga de la interfaz de usuario y la representación de la información, mientras que el servidor se ocupa de procesar las solicitudes del cliente y gestionar los recursos.
Comunicación sin estado: la comunicación entre cliente y servidor debe ser sin estado, es decir, cada petición del cliente al servidor debe contener toda la información necesaria para que el servidor pueda procesarla. El servidor no debe almacenar información sobre el estado del cliente entre peticiones, lo que permite una mayor escalabilidad y facilidad de gestión del sistema.
Caché: los sistemas REST permiten la utilización de la caché para mejorar la eficiencia, el rendimiento y la escalabilidad de la aplicación. Los recursos pueden ser almacenados en caché por el cliente, evitando la necesidad de solicitar repetidamente la misma información al servidor.
Sistema en capas: la arquitectura REST promueve la organización del sistema en capas, lo que facilita la separación de responsabilidades y la encapsulación de funcionalidades. Cada capa se comunica únicamente con la capa inmediatamente superior e inferior, lo que simplifica la evolución y el mantenimiento del sistema.
Código bajo demanda: este principio, aunque opcional, permite extender la funcionalidad del cliente mediante el envío de código ejecutable desde el servidor. Esto puede mejorar la adaptabilidad del sistema, pero también puede aumentar la complejidad y la seguridad del cliente.
Interfaz uniforme: la arquitectura REST establece un conjunto de restricciones y convenciones para garantizar una interfaz común y consistente entre los componentes del sistema. Algunas de estas convenciones incluyen la identificación de recursos mediante URI (Uniform Resource Identifier), el uso de métodos HTTP estándar (GET, POST, PUT, DELETE) y la representación de recursos utilizando formatos estandarizados (como XML o JSON).
Cuando se aplican estos principios de diseño a la arquitectura del sistema, este adquiere propiedades no funcionales deseables, como rendimiento, escalabilidad, simplicidad, modificabilidad, visibilidad, portabilidad y fiabilidad. Estas características hacen que las aplicaciones basadas en REST sean más fáciles de desarrollar, mantener y evolucionar, lo que resulta en un mayor éxito en el desarrollo de proyectos y sistemas basados en este estilo arquitectónico.
Caché es una memoria de acceso rápido que almacena copias de datos o instrucciones frecuentemente utilizadas para acelerar el tiempo de respuesta de un sistema. Ayuda a reducir la latencia al proporcionar acceso rápido a datos previamente recuperados, evitando acceder a fuentes de datos más lentas como la memoria principal o el disco.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
Los principios de diseño a menudo se denominan también restricciones arquitectónicas porque definen los límites y condiciones que deben cumplirse para garantizar la coherencia, la interoperabilidad y el funcionamiento adecuado de los sistemas basados en REST.
"La vida es un sistema de objetos distribuidos. Sin embargo, la comunicación entre seres humanos es un sistema de hipermedia distribuido, donde el intelecto de la mente, la voz + gestos, los ojos + oídos y la imaginación son todos componentes."
El término RESTful se refiere a la implementación de aplicaciones y servicios web que cumplen con los principios fundamentales y restricciones arquitectónicas de la arquitectura REST (Representational State Transfer).
Una API RESTful es una API (Application Programming Interface) de tipo servicio web que permite la interacción entre dos sistemas informáticos utilizando un estilo de arquitectura de transferencia de estado representacional (REST). Aunque puede implementarse sobre varios protocolos de red, HTTP es el más comúnmente usado para los servicios web RESTful, debido a su universalidad y amplia adopción en la web.
Es importante aclarar que los servicios web son un tipo de API. Todos los servicios web son API, pero no todas las API son servicios web. API es la categoría más amplia porque, por definición, se refiere a cualquier componente de software que actúa como intermediario entre dos aplicaciones.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
Una HTTP RESTful API es una interfaz de programación de aplicaciones (API) que sigue los principios de diseño REST, utilizando el protocolo de transferencia de hipertexto (HTTP) como medio de comunicación entre cliente y servidor. Esta API es un tipo de servicio web que facilita la interacción entre distintos sistemas y plataformas, proporcionando una forma estandarizada y eficiente de acceder a recursos y servicios.
Algunos de los aspectos clave que caracterizan a una HTTP RESTful API son los siguientes:
Métodos HTTP: Las APIs RESTful utilizan métodos HTTP estándar para realizar operaciones sobre los recursos. Estos métodos incluyen GET (para obtener recursos), POST (para crear nuevos recursos), PUT (para actualizar recursos existentes) y DELETE (para eliminar recursos). La utilización de estos métodos proporciona un conjunto de operaciones básicas y fácilmente comprensibles.
URI de recursos: Cada recurso en una API RESTful se identifica mediante una URI única, lo que facilita su localización y acceso. Las URI deben ser descriptivas y jerárquicas, permitiendo la organización de recursos en colecciones y subcolecciones.
Representación de recursos: Los recursos en una API RESTful se representan utilizando formatos estandarizados, como JSON o XML. Estos formatos permiten la fácil transmisión y manipulación de datos entre sistemas y plataformas, simplificando la interoperabilidad. En los últimos años, JSON se ha convertido en el formato más utilizado en la representación de recursos debido a su simplicidad y facilidad de uso.
A continuación se muestra un ejemplo de una HTTP RESTful API para un sistema de gestión de libros:
URI
GET
POST
PUT
DELETE
/libros
Obtiene una lista de todos los libros.
Crea un nuevo libro.
No aplica.
Elimina todos los libros.
/libros/{id}
Obtiene el libro con el identificador {id}.
No aplica.
Actualiza el libro con el identificador {id}.
Elimina el libro con el identificador {id}.
En este ejemplo, la API permite gestionar una lista de libros utilizando diferentes métodos HTTP y URI:
GET /libros: obtiene una lista de todos los libros. Esta operación no requiere ningún parámetro adicional y devuelve una lista de libros que estarían generalmente en formato JSON.
POST /libros: crea un nuevo libro con los datos proporcionados en el cuerpo de la petición, que normalmente estarían en formato JSON. Los datos incluirían propiedades como título, autor y fecha de publicación.
PUT /libros/{id}: actualiza el libro con el identificador {id} utilizando los datos proporcionados en el cuerpo de la petición, también en formato JSON. La petición debe incluir todos los campos relevantes que se deseen actualizar, como título, autor o fecha de publicación.
DELETE /libros: elimina todos los libros de la lista. Esta operación no requiere parámetros adicionales y, una vez completada, la lista de libros estará vacía.
GET /libros/{id}: obtiene el libro con el identificador {id}. Esta operación requiere el identificador del libro en la URI y devuelve los detalles del libro en formato JSON.
DELETE /libros/{id}: elimina el libro con el identificador {id}. Esta operación requiere el identificador del libro en la URI y elimina el libro correspondiente de la lista.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
Para un mejor uso de las HTTP RESTful API, aquí hay algunos puntos clave a tener en cuenta. Primero, es importante que las URI sean claras y describan bien los datos que se están exponiendo. También, cuando ocurra un error, la API debe proporcionar respuestas que ayuden a entender qué salió mal. La seguridad también es esencial, por lo que se deben tomar medidas como la autenticación y la autorización, y se debe considerar el uso de HTTPS para cifrar la comunicación. Si se realizan cambios en la API que no son compatibles con versiones anteriores, se debe utilizar versionado para evitar problemas a los usuarios actuales. Por último, una buena documentación de la API, incluyendo ejemplos de uso, facilitará su uso y comprensión.
Diseña una HTTP RESTful API para un sistema de gestión de películas que permita realizar las siguientes operaciones: obtener una lista de todas las películas, crear una nueva película, actualizar los detalles de una película existente, actualizar una película existente y eliminar una película.
En la empresa TechFlow, Manuel y Carlos están trabajando en la mejora de un sistema de monitoreo de redes sociales para sus clientes. Este sistema rastrea las menciones de sus clientes en diversas plataformas de medios sociales y recopila todos los datos en un lugar centralizado para su análisis.
Una de las características esenciales del proyecto es la capacidad de consumir servicios web SOAP y REST a través de HTTP para acceder a los datos de las plataformas de redes sociales. Por tanto, Manuel y Carlos analizan soluciones que sean gratuitas, libres, fáciles de usar y que puedan integrarse bien con su pila de tecnología existente. Para ello, estudian la posibilidad de usar clientes HTTP como la herramienta HTTPie, o la biblioteca Guzzle.
El consumo de servicios web se refiere al proceso de acceder y utilizar las funcionalidades proporcionadas por un servicio web en una aplicación o sistema. Los servicios web, como hemos visto, pueden ser implementados mediante diferentes protocolos y arquitecturas, como SOAP y REST. Estos servicios exponen sus funcionalidades a través de interfaces y métodos que pueden ser invocados por los clientes (también conocidos como consumidores de servicios web) utilizando tecnologías como HTTP, siendo esta la más utilizada en la actualidad.
Para consumir un servicio web, el cliente debe conocer la estructura y las especificaciones del servicio, como la ubicación (URL), los métodos disponibles y los parámetros que se requieren para cada método. Esta información suele ser proporcionada por el proveedor del servicio a través de documentación, archivos de descripción del servicio (como WSDL en el caso de SOAP), o estándares de diseño en el caso de servicios RESTful.
El consumo de servicios web es una práctica común en el desarrollo de software, ya que permite la integración y comunicación entre diferentes sistemas y aplicaciones. Esto es especialmente útil cuando se requiere acceder a funcionalidades o datos proporcionados por un tercero, como bases de datos, sistemas de autenticación, procesamiento de pagos, entre otros.
El consumo de servicios web en HTTP se realiza generalmente utilizando clientes HTTP. Estos clientes son herramientas o aplicaciones que permiten enviar solicitudes y recibir respuestas desde y hacia servicios web a través del protocolo HTTP. Estos clientes son particularmente útiles para probar, depurar o interactuar con APIs y servicios web.
Una URL (Uniform Resource Locator) es una dirección web que identifica de manera única una página o recurso en Internet. Consiste en un protocolo seguido por el nombre de dominio y la ruta al recurso específico.
WSDL (Web Services Description Language) es un lenguaje basado en XML que describe la interfaz de servicios web. Proporciona información sobre los métodos disponibles, los formatos de datos admitidos y la ubicación del servicio. Es utilizado para facilitar la comunicación entre aplicaciones distribuidas en la web.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
HTTPie es un cliente moderno y fácil de usar para realizar solicitudes HTTP. Su objetivo es simplificar la interacción con servicios web de tipo HTTP API RESTful, haciendo más sencillo y amigable el proceso de depuración, prueba y exploración de dichos servicios. HTTPie es gratuita, de código abierto y compatible con varias plataformas, incluyendo Windows, macOS y GNU/Linux.
HTTPie se presenta en tres versiones distintas: Desktop, Terminal y Web App. La versión Desktop proporciona una interfaz gráfica de usuario intuitiva que simplifica el proceso de hacer solicitudes HTTP, permitiendo a los usuarios interactuar con APIs y servicios web de forma visual. La versión Terminal es la más tradicional, siendo una herramienta de línea de comandos que ofrece potentes funciones y personalización para usuarios avanzados que prefieren trabajar con el teclado y la terminal. Por último, la Web App es una versión en línea que permite realizar solicitudes HTTP desde cualquier navegador, ofreciendo así una solución multiplataforma y accesible sin necesidad de instalar software adicional.
Es recomendable usar la versión de terminal de HTTPie, ya que es la más potente, personalizada y profesional. Una vez instalado siguiendo los pasos de correspondientes al sistema operativo utilizado, puedes comprobar si funciona correctamente en tu terminal ejecutando el siguiente comando y presionando la tecla Intro:
http --version
Este comando mostrará la versión de HTTPie que tienes instalada en tu sistema.
A continuación, ejecuta un ejemplo usando HTTPie:
https httpie.io/hello
En este caso, https es un alias para http --default-scheme=https, y httpie.io/hello es la URL a la que se enviará la solicitud. Como no se especificó un método, se utilizará el método GET por defecto.
Para obtener más información y ayuda sobre el uso de HTTPie, puedes ejecutar el siguiente comando en la terminal:
http --help
Existe otra herramienta más versátil y ampliamente utilizada denominada cURL que puede ser más adecuada en ciertos escenarios o cuando se necesitan características más avanzadas y personalizadas. La herramienta cURL es compatible con varios protocolos, incluyendo HTTP, HTTPS, FTP, FTPS, SCP, SFTP, TFTP, LDAP, DICT, TELNET, IMAP, SMTP, POP3 y muchos más. Además de realizar solicitudes básicas GET y POST, cURL también admite una amplia gama de opciones y funciones avanzadas, como la personalización de encabezados, el manejo de cookies, la autenticación, la descarga de archivos, la transferencia de datos, el seguimiento de redirecciones y más.
Sin embargo, HTTPie ofrece una experiencia más intuitiva y amigable con respecto a cURL para los desarrolladores al realizar solicitudes HTTP desde la línea de comandos, gracias a su sintaxis legible, salida formateada, soporte nativo para JSON y otras características convenientes.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
HTTPS (Hypertext Transfer Protocol Secure) es una versión segura de HTTP que utiliza criptografía para proteger la comunicación entre clientes y servidores en internet. Proporciona autenticación, integridad y confidencialidad de los datos, asegurando la privacidad y seguridad de la información transmitida.
FTP (File Transfer Protocol) es un protocolo de red utilizado para la transferencia de archivos entre un cliente y un servidor en una red TCP/IP. Permite subir, descargar, renombrar y eliminar archivos, así como navegar por directorios en el servidor remoto.
FTPS (File Transfer Protocol Secure) es una extensión segura del protocolo FTP que utiliza SSL/TLS para cifrar la comunicación entre el cliente y el servidor. Proporciona autenticación y cifrado de datos, garantizando la seguridad y confidencialidad en la transferencia de archivos.
SCP (Secure Copy Protocol) es un protocolo de red que permite la transferencia segura de archivos entre un cliente y un servidor remoto. Utiliza SSH para la autenticación y el cifrado de los datos, asegurando la confidencialidad e integridad de la información transferida.
SFTP (Secure File Transfer Protocol) es un protocolo de transferencia de archivos seguro que combina las funcionalidades del FTP con la seguridad del protocolo SSH. Permite transferir archivos de manera encriptada y autenticada, protegiendo la integridad y confidencialidad de la información.
TFTP (Trivial File Transfer Protocol) es un protocolo simple de transferencia de archivos utilizado principalmente en entornos de red de área local. Se utiliza para enviar y recibir archivos pequeños, como configuraciones de dispositivos de red, sin autenticación ni encriptación de datos.
LDAP (Lightweight Directory Access Protocol) es un protocolo estándar de acceso a directorios que permite a los sistemas consultar, actualizar y administrar información almacenada en un servicio de directorio. Se utiliza comúnmente para la autenticación y el acceso a información de usuarios y recursos en redes empresariales.
DICT (Dictionary Protocol) es un protocolo de red que permite buscar y recuperar información de diccionarios en línea. Proporciona definiciones, sinónimos, antónimos y otros datos lingüísticos, y se utiliza en aplicaciones y herramientas de referencia y traducción en línea.
TELNET es un protocolo de red que permite la comunicación bidireccional y el control remoto de dispositivos a través de una red. Permite el acceso a una terminal remota para ejecutar comandos y gestionar dispositivos de forma remota, pero carece de seguridad y encriptación.
IMAP (Internet Message Access Protocol) es un protocolo de correo electrónico que permite a los usuarios acceder y administrar sus mensajes de correo electrónico almacenados en un servidor remoto. Permite sincronizar los mensajes entre diferentes dispositivos y ofrece funciones avanzadas de búsqueda y organización de correos electrónicos.
SMTP (Simple Mail Transfer Protocol) es un protocolo de red utilizado para enviar correos electrónicos a través de Internet. Actúa como un sistema de entrega de correo electrónico, permitiendo el envío y retransmisión de mensajes entre servidores de correo electrónico.
POP3 (Post Office Protocol 3) es un protocolo de correo electrónico que permite a los usuarios descargar y acceder a sus mensajes de correo electrónico desde un servidor remoto. Los mensajes se descargan al dispositivo local y pueden ser gestionados sin conexión a Internet.
HTTPie es una herramienta poderosa para interactuar con HTTP API RESTful, facilitando la depuración, prueba y exploración de estos servicios web. Para aprender más sobre HTTPie, puedes consultar la documentación oficial, la cual ofrece guías detalladas y tutoriales sobre cómo usarlo efectivamente. También puedes visitar el repositorio de GitHub de HTTPie para acceder al código fuente, contribuir al proyecto, reportar errores y seguir los últimos desarrollos.
Guzzle es una biblioteca de PHP ampliamente utilizada para enviar solicitudes HTTP y manejar respuestas en aplicaciones web. La principal ventaja de utilizar Guzzle es su capacidad para gestionar múltiples peticiones de forma eficiente, así como proporcionar una interfaz más fácil de usar en comparación con las funciones nativas de PHP para realizar solicitudes HTTP. Además, Guzzle es la biblioteca que se usa como cliente HTTP por defecto en Laravel.
Para instalar Guzzle en un proyecto de PHP, se debe utilizar el gestor de paquetes Composer ejecutando el siguiente comando en la terminal:
composer require guzzlehttp/guzzle
A continuación, se presenta un ejemplo sencillo de cómo utilizar Guzzle para realizar una solicitud HTTP GET:
En este ejemplo, primero se carga el archivo autoload generado por Composer para cargar las dependencias del proyecto. A continuación, se crea una instancia de la clase Client de Guzzle. Luego, se realiza una solicitud URL, que corresponde al repositorio de Guzzle en GitHub, y se obtiene el contenido de la respuesta en formato JSON. Después, se decodifica el JSON en el array asociativo $data y se imprime en pantalla el código de estado HTTP de la respuesta y los datos recibidos.
Como se mencionó anteriormente, Guzzle está integrado por defecto en el frameworkLaravel. Esto facilita la implementación de servicios web y la comunicación entre aplicaciones basadas en Laravel. Un ejemplo de cómo realizar una solicitud GET básica a otra URL sería el siguiente:
use Illuminate\Support\Facades\Http;
$response = Http::get('http://ejemplo.com');
Toda la información de cómo realizar solicitudes HTTP en Laravel con Guzzle lo indican en su documentación.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
Existen varias formas de consumir servicios web SOAP en PHP. Una de las opciones más comunes y ampliamente utilizadas es a través de la clase SoapClient. Esta clase proporciona funcionalidades que facilitan el proceso de envío de solicitudes y recepción de respuestas desde servicios web SOAP.
A continuación, se presentan dos ejemplos de consumir servicios SOAP en PHP: una usando WSDL (la opción más recomendable) y otra sin usarlo. En dichos ejemplos, el resultado de la conversión de temperatura se extrae de la respuesta y se muestra en pantalla.
En primer lugar, se presenta un ejemplo sobre cómo consumir un servicio web SOAP con WSDL en PHP:
Al utilizar SOAP sin WSDL, es fundamental tener un buen conocimiento sobre cómo construir manualmente el cuerpo de la solicitud y procesar la respuesta XML recibida. Esto implica comprender la estructura y el esquema de los mensajes SOAP, así como conocer los elementos y atributos necesarios para interactuar con el servicio web correctamente.
Las clases SoapClient y SoapServer de PHP no soportan la versión más reciente del lenguaje de descripción de servicios web, WSDL 2.0, lo que puede limitar la compatibilidad con ciertos servicios web. Además, no se sabe si PHP incluirá soporte para WSDL 2.0 en el futuro en dichas clases, ya que las HTTP RESTful API, que son generalmente más simples y flexibles que los servicios web SOAP, han ganado mucha popularidad. Por lo tanto, si vas a trabajar con servicios web SOAP en PHP, debes considerar estas limitaciones y evaluar si otras bibliotecas de terceros que soporten WSDL 2.0 u otras tecnologías de servicios web, como las HTTP RESTful API, podrían ser una opción más adecuada para tu proyecto.
El consumo de servicios web REST consiste en interactuar con servicios web que siguen los principios de la arquitectura REST. Al utilizar el protocolo HTTP, es posible realizar operaciones como crear, leer, actualizar y eliminar (CRUD) recursos dados por una API RESTful. Para este propósito, se pueden emplear diferentes herramientas y librerías, siendo una de las más populares para PHP Guzzle, un cliente HTTP.
A continuación, se presentan cuatro ejemplos con Guzzle para interactuar con la API de JSONPlaceholder. Es importante mencionar que debes tener instalado Guzzle previamente y que es recomendable hacerlo a través de Composer.
En el primer ejemplo se obtiene todas las publicaciones del usuario 2. Para lograr esto, se realiza una solicitud GET al endpoint correspondiente, utilizando el método get de Guzzle. El siguiente código ilustra cómo hacerlo:
En el segundo ejemplo se crea un nuevo comentario en la publicación 3. Para crear un nuevo comentario, es necesario enviar una solicitud POST al endpoint adecuado. Se utiliza el método post de Guzzle y se envían los datos del comentario en el cuerpo de la solicitud. El siguiente código muestra cómo realizar esta acción:
En el tercer ejemplo se actualiza o modifica la publicación 5. La actualización de un recurso se realiza mediante una solicitud PUT al endpoint correspondiente. En este caso, se utiliza el método put de Guzzle, y se envían los datos actualizados en el cuerpo de la solicitud. El siguiente código ilustra cómo actualizar una publicación:
En el cuarto y último ejemplo se borra el usuario 7. Para eliminar un recurso, se envía una solicitud DELETE al endpoint adecuado. En este código, se emplea el método deletede Guzzle para eliminar al usuario con ID 7:
<?php
require 'vendor/autoload.php';
$client = new GuzzleHttp\Client(['base_uri' => 'https://jsonplaceholder.typicode.com']);
$userId = 7;
$response = $client->delete("/users/{$userId}");
if ($response->getStatusCode() === 200)
{
echo "Usuario eliminado con éxito.";
}
Estos ejemplos demuestran cómo Guzzle facilita el consumo de servicios web REST en PHP, permitiendo una interacción eficiente y estructurada con las HTTP API RESTful.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
En la empresa ProWeb Solutions, Daniela y Sofía desarrollan un sistema de gestión de reservas para un conjunto de hoteles. Para promover la interoperabilidad y reutilización del código, optan por la creación de servicios web utilizando PHP.
Para consultas de disponibilidad de habitaciones en tiempo real, implementan un servicio web con SOAP, que puede ser consumido por clientes en cualquier lenguaje de programación. Paralelamente, desarrollan un servicio web REST en PHP para acceder a la información de las reservas realizadas, aprovechando su ligereza y facilidad de uso para operaciones sin estado.
Finalmente, utilizan Laravel, un framework de PHP, para manejar operaciones de back-office, como la gestión de habitaciones y tarifas. Laravel les facilita la creación de servicios web con herramientas para interactuar con la base de datos, autenticación basada en tokens y la capacidad de crear rutas API de manera organizada.
El consumo de servicios web a través de HTTP es muy popular y consiste en realizar solicitudes HTTP a URL específicas que representan diferentes recursos en un servicio web. Estas solicitudes pueden ser para obtener datos (GET), enviar datos (POST), actualizar datos (PUT/PATCH) o eliminar datos (DELETE). Cada solicitud a un servicio web retorna una respuesta, que contiene cualquier dato solicitado, así como un código de estado HTTP que indica si la solicitud fue exitosa.
Los servicios web pueden ser consumidos por clientes HTTP, que pueden ser aplicaciones para la terminal, aplicaciones web o incluso pueden ser bibliotecas. Para interactuar con los servicios web, los clientes HTTP utilizan encabezados para transmitir información sobre la solicitud.
Existen muchas herramientas y bibliotecas para facilitar el consumo de servicios web, tales como HTTPie, Guzzle, y muchas otras. Estas herramientas simplifican el proceso de creación de solicitudes HTTP, manejo de respuestas, y manejo de errores.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
Postman es una herramienta esencial para probar y explorar servicios web. Permite realizar todas las operaciones RESTful (GET, POST, PUT, DELETE, etc.), añadir parámetros a las solicitudes, establecer encabezados y gestionar diferentes tipos de autenticación. Además, ayuda a organizar las solicitudes en colecciones, facilitando el mantenimiento de pruebas y consultas a servicios web.
Con su funcionalidad para automatizar pruebas mediante scripts en JavaScript, Postman simplifica considerablemente el proceso de pruebas y exploración de servicios web. Por su versatilidad y utilidad, se ha convertido en una herramienta imprescindible para cualquier desarrollador que trabaje con servicios web.
Una aplicación de suma es un ejemplo muy sencillo para ilustrar la implementación de un servicio web empleando SOAP en PHP. Este ejemplo utiliza SOAP 1.2 y WSDL 1.1. Se empleará un servidor local de SOAP usando SoapServer y se desarrollará un cliente utilizando SoapClient.
Paso 1: Creación del archivo WSDL
Primero, se necesita crear un archivo WSDL que describa las operaciones disponibles en el servicio web. Para este ejemplo, vamos a definir solo una operación básica, la de suma, para el servicio que hemos denominado SumaService. Para ello, crea una carpeta dentro de htdocs de XAMPP que se llame servicio_web_simple y dentro de dicha carpeta crea el archivo suma.wsdlcon el siguiente código WSDL:
Este código define mensajes de solicitud sumaRequest y respuesta sumaResponse, un tipo de puerto SumaPortType con una operación suma, una conexión SumaBinding y un servicio SumaService con un puerto específico SumaPort. Los mensajes toman dos enteros como entrada y devuelven un entero. La operación suma está vinculada al endpoint http://localhost:8080/soap-servidor.php a través del protocolo HTTP.
Paso 2: Implementación del servicio web y creación del servidor SOAP
Crea el archivo soap-servidor.php. En este archivo, se definirá la clase SumaService con el métodos de la operación suma y se creará un servidor SOAP con el WSDL creado anteriormente:
<?php
class SumaService {
public function suma(int $a, int $b): int {
return $a + $b;
}
}
$options = [
'uri' => 'http://localhost/soap-servidor.php',
'encoding' => 'UTF-8',
'soap_version' => SOAP_1_2
];
$server = new SoapServer('suma.wsdl', $options);
$server->setClass(SumaService::class);
$server->handle();
Aquí está definido el servicio SumaService y el servidor SOAP. Ahora, puedes crear un cliente SOAP para interactuar con él.
Paso 3: Creación del Cliente SOAP
Crear un cliente SOAP es bastante simple. Para ello crea el archivo soap-cliente.php. Solo necesitas especificar la ubicación del archivo WSDL al instanciar la clase SoapClient.
Este código crea un cliente SOAP utilizando la biblioteca SoapClient y el archivo WSDL suma.wsdl. Luego, llama al método suma en el servicio web con los argumentos 5 y 7. Si la llamada es exitosa, imprime el resultado, si no, imprime el mensaje de error.
Paso 4: Ejecución del servidor y cliente SOAP
Inicia el servidor PHP en localhost en el puerto 8080 ejecutando el siguiente comando en tu terminal dentro de la carpeta servicio_web_simple:
php -S localhost:8080
Asegúrate de que los archivos suma.wsdl, soap-servidor.php y soap-cliente.php estén en dicha carpeta creada.
Ahora, desde otro terminal o línea de comandos, ejecuta el archivo soap-client.php:
php soap-cliente.php
Deberías ver la siguiente salida:
El resultado de la suma es: 12.
Esto indica que el cliente SOAP pudo conectarse correctamente al servidor SOAP, realizar la operación de suma, recibir el resultado e imprimirlo en pantalla.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
Un servicio web REST en PHP puede ser implementado para gestionar canciones de forma eficiente. Los servicios web REST, también conocidos como RESTful, utilizan HTTP para comunicarse y pueden manejar diferentes tipos de solicitudes como GET, POST, PUT y DELETE.
Paso 1: Creación de la base de datos y configuración de la conexión
Para empezar, crea una base de datos para almacenar la información de las canciones. Para ello, utiliza phpMyAdmin, que se incluye con XAMPP, y crea una base de datos llamada canciones_db y una tabla llamada canciones con los campos id, titulo, artista y genero con cinco inserciones de ejemplo:
CREATE DATABASE canciones_db;
USE canciones_db;
CREATE TABLE canciones (
id INT AUTO_INCREMENT PRIMARY KEY,
titulo VARCHAR(255) NOT NULL,
artista VARCHAR(255) NOT NULL,
genero VARCHAR(255) NOT NULL
);
INSERT INTO canciones (titulo, artista, genero) VALUES ('Child In Time', 'Deep Purple', 'Rock');
INSERT INTO canciones (titulo, artista, genero) VALUES ('Shape of You', 'Ed Sheeran', 'Pop');
INSERT INTO canciones (titulo, artista, genero) VALUES ('Billie Jean', 'Michael Jackson', 'Pop');
INSERT INTO canciones (titulo, artista, genero) VALUES ('Hotel California', 'Eagles', 'Rock');
INSERT INTO canciones (titulo, artista, genero) VALUES ('Fear of the Dark', 'Iron Maiden', 'Heavy Metal');
A continuación, crea una carpeta denominada rest_cancionesque será el nombre de tu proyecto y crea un archivo en él llamado Database.phppara gestionar la conexión a la base de datos usando PDO:
<?php
class Database
{
private $host = "localhost";
private $db_name = "canciones_db";
private $username = "root";
private $password = "";
public $conn;
public function getConnection() {
$this->conn = null;
try {
$this->conn = new PDO("mysql:host=" . $this->host . ";dbname=" . $this->db_name, $this->username, $this->password);
} catch(PDOException $exception) {
echo "Error de conexión: " . $exception->getMessage();
}
return $this->conn;
}
}
El código es una clase llamada Database que establece una conexión con una base de datos MariaDB/MySQL utilizando la extensión PDO. Define propiedades para la información de conexión y un método llamado getConnection que intenta establecer la conexión y devuelve el objeto de conexión PDO.
Paso 2: Crea el modelo de las canciones
Crea un archivo llamado Cancion.php. Este archivo representará el modelo de tus datos y contendrá los métodos CRUD:
<?php
class Cancion {
private $conn;
private $table_name = "canciones";
public $id;
public $titulo;
public $artista;
public $genero;
public function __construct($db) {
$this->conn = $db;
}
// Obtener todas las canciones
public function getAll() {
$query = "SELECT * FROM " . $this->table_name;
$stmt = $this->conn->prepare($query);
$stmt->execute();
return $stmt;
}
// Obtener una canción
public function getOne() {
$query = "SELECT * FROM " . $this->table_name . " WHERE id = ?";
$stmt = $this->conn->prepare($query);
$stmt->bindParam(1, $this->id);
$stmt->execute();
return $stmt;
}
// Añadir canción
public function create() {
$query = "INSERT INTO " . $this->table_name . " SET titulo = :titulo, artista = :artista, genero = :genero";
$stmt = $this->conn->prepare($query);
$this->titulo = htmlspecialchars(strip_tags($this->titulo));
$this->artista = htmlspecialchars(strip_tags($this->artista));
$this->genero = htmlspecialchars(strip_tags($this->genero));
$stmt->bindParam(":titulo", $this->titulo);
$stmt->bindParam(":artista", $this->artista);
$stmt->bindParam(":genero", $this->genero);
if ($stmt->execute()) {
return true;
}
return false;
}
// Actualizar canción
public function update() {
$query = "UPDATE " . $this->table_name . " SET titulo = :titulo, artista = :artista, genero = :genero WHERE id = :id";
$stmt = $this->conn->prepare($query);
$this->titulo = htmlspecialchars(strip_tags($this->titulo));
$this->artista = htmlspecialchars(strip_tags($this->artista));
$this->genero = htmlspecialchars(strip_tags($this->genero));
$this->id = htmlspecialchars(strip_tags($this->id));
$stmt->bindParam(":titulo", $this->titulo);
$stmt->bindParam(":artista", $this->artista);
$stmt->bindParam(":genero", $this->genero);
$stmt->bindParam(":id", $this->id);
if ($stmt->execute()) {
return true;
}
return false;
}
// Borrar canción
public function delete() {
$query = "DELETE FROM " . $this->table_name . " WHERE id = ?";
$stmt = $this->conn->prepare($query);
$this->id = htmlspecialchars(strip_tags($this->id));
$stmt->bindParam(1, $this->id);
if ($stmt->execute()) {
return true;
}
return false;
}
}
Este código define una clase Cancion para interactuar con una base de datos de canciones_db. Contiene métodos para obtener todas las canciones (getAll), obtener una canción específica por id (getOne), agregar una nueva canción (create), actualizar una canción existente (update) y eliminar una canción (delete). Los datos de la canción se manejan utilizando instrucciones SQL preparadas y los valores de entrada se tratan para proteger contra ataques de inyección SQL.
Paso 3: Creación del servicio web REST
Ahora, crearemos el archivo PHP que actuará como nuestro servicio web REST. En la carpeta htdocs de XAMPP, cree un nuevo archivo llamado api_canciones.php. En este archivo, necesitaremos conectar con la base de datos y manejar las solicitudes HTTP que recibamos:
<?php
header("Content-Type: application/json");
header("Access-Control-Allow-Origin: *");
header("Access-Control-Allow-Methods: GET, POST, PUT, DELETE");
header("Access-Control-Allow-Headers: Content-Type");
include_once 'Database.php';
include_once 'Cancion.php';
$database = new Database();
$db = $database->getConnection();
$cancion = new Cancion($db);
$request = json_decode(file_get_contents("php://input"));
switch($_SERVER['REQUEST_METHOD'])
{
case 'GET':
$id = $_GET['id'] ?? null;
if ($id) {
$cancion->id = $id;
$stmt = $cancion->getOne();
$row = $stmt->fetch(PDO::FETCH_ASSOC);
if ($row) {
$cancion_arr = array(
"id" => $row['id'],
"titulo" => $row['titulo'],
"artista" => $row['artista'],
"genero" => $row['genero']
);
echo json_encode($cancion_arr);
} else {
echo json_encode(array("message" => "La canción no existe."), JSON_UNESCAPED_UNICODE);
}
} else {
$stmt = $cancion->getAll();
$num = $stmt->rowCount();
if($num > 0) {
$canciones_arr = array();
while ($row = $stmt->fetch(PDO::FETCH_ASSOC)) {
extract($row);
$cancion_item = array(
"id" => $id,
"titulo" => $titulo,
"artista" => $artista,
"genero" => $genero
);
array_push($canciones_arr, $cancion_item);
}
echo json_encode($canciones_arr);
} else {
echo json_encode(array("message" => "No se encontraron canciones."));
}
}
break;
case 'POST':
$cancion->titulo = $request->titulo;
$cancion->artista = $request->artista;
$cancion->genero = $request->genero;
if ($cancion->create()) {
echo json_encode(array("message" => "Canción creada correctamente."), JSON_UNESCAPED_UNICODE);
} else {
echo json_encode(array("message" => "Error al crear la canción."), JSON_UNESCAPED_UNICODE);
}
break;
case 'PUT':
if (!isset($request->id)) {
echo json_encode(array("message" => "Es necesario el ID de la canción."), JSON_UNESCAPED_UNICODE);
exit(0);
}
$cancion->id = $request->id;
$cancion->titulo = $request->titulo;
$cancion->artista = $request->artista;
$cancion->genero = $request->genero;
if ($cancion->update()) {
echo json_encode(array("message" => "Canción actualizada correctamente."), JSON_UNESCAPED_UNICODE);
} else {
echo json_encode(array("message" => "Error al actualizar la canción."), JSON_UNESCAPED_UNICODE);
}
break;
case 'DELETE':
if (!isset($request->id)) {
echo json_encode(array("message" => "Es necesario el id de la canción."), JSON_UNESCAPED_UNICODE);
exit(0);
}
$cancion->id = $request->id;
if ($cancion->delete()) {
echo json_encode(array("message" => "Canción eliminada correctamente."), JSON_UNESCAPED_UNICODE);
} else {
echo json_encode(array("message" => "Error al eliminar la canción."), JSON_UNESCAPED_UNICODE);
}
break;
default:
http_response_code(405);
echo json_encode(array("message" => "Método no permitido."), JSON_UNESCAPED_UNICODE);
}
Este código maneja operaciones CRUD en la base de datos de canciones. Dependiendo del método HTTP (GET, POST, PUT, DELETE), el código realiza diferentes funciones: obtiene todas las canciones o una específica (GET), crea una nueva canción (POST), actualiza una canción existente (PUT), o elimina una canción (DELETE). Las respuestas y solicitudes se gestionan en formato JSON. Los errores en las solicitudes resultan en mensajes claros enviados de vuelta al cliente.
Paso 4: Consumo del servicio web
Finalmente, vamos a consumir nuestro servicio web REST utilizando Guzzle. Asegúrate de haber instalado previamente Guzzle mediante Composer. Luego, crea un archivo llamado cliente.php y añade el siguiente código:
<?php
require 'vendor/autoload.php';
use GuzzleHttp\Client;
$client = new Client(['base_uri' => 'http://localhost/rest_canciones/api_canciones.php']);
// Obtener todas las canciones
$response = $client->request('GET', '');
echo "Obtener todas las canciones:<br /><br />";
echo $response->getBody();
echo "<br />---------------------<br /><br />";
// Obtener una canción
$response = $client->request('GET', '', ['query' => ['id' => 1]]);
echo "Obtener la canción con ID 1:<br /><br />";
echo $response->getBody();
echo "<br />---------------------<br /><br />";
// Añadir una canción
$response = $client->request('POST', '', [
'json' => [
'titulo' => 'Smells Like Teen Spirit',
'artista' => 'Nirvana',
'genero' => 'Grunge'
]
]);
echo "Añadir una canción:<br /><br />";
echo $response->getBody();
echo "<br />---------------------<br /><br />";
// Actualizar una canción
$response = $client->request('PUT', '', [
'json' => [
'id' => 2,
'titulo' => 'Smile',
'artista' => 'Katy Perry',
'genero' => 'Pop'
]
]);
echo "Actualizar la canción con ID 2:<br /><br />";
echo $response->getBody();
echo "<br />---------------------<br /><br />";
// Borrar una canción
$response = $client->request('DELETE', '', [
'json' => [
'id' => 3
]
]);
echo "Borrar la canción con ID 3:<br /><br />";
echo $response->getBody();
echo "<br />---------------------<br /><br />";
Este código realiza operaciones CRUD a través de una API REST de canciones. Cada operación tiene una petición HTTP correspondiente (GET, POST, PUT, DELETE).
Por último, para probar tu servicio web REST, debes ejecutar el archivo cliente.php en tu servidor local.
Es importante recordar que este es un ejemplo básico y que en una implementación real se requerirían medidas adicionales de seguridad y validación. Por ejemplo, en lugar de enviar los datos en texto sin formato, se podría considerar el uso de tokens de autenticación, HTTPS y otras técnicas para proteger los datos.
También, aunque se ha utilizado Guzzle para realizar solicitudes HTTP en PHP, se puede utilizar cualquier otra biblioteca de cliente HTTP o incluso herramientas como HTTPie para probar este servicio web REST.
CRUD (Create, Read, Update, Delete) es un acrónimo que representa las operaciones básicas en sistemas de gestión de bases de datos. Create (Crear) permite agregar nuevos registros, Read (Leer) recupera información existente, Update (Actualizar) modifica datos existentes y Delete (Eliminar) borra registros.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
En el ejemplo que hemos visto, cualquier persona que tenga acceso a tu servidor web puede interactuar con tus datos. Eso puede estar bien para un proyecto personal o para aprendizaje, pero no es adecuado para una aplicación real. Los sistemas de autenticación como OAuth 2.0, JWT (JSON Web Tokens) o incluso una simple autenticación básica HTTP pueden ayudarte a controlar quién puede interactuar con tus datos.
Incluso con un buen sistema de autenticación, tus datos pueden ser interceptados por personas malintencionadas si no usas una conexión segura. Por eso, es importante usar siempre que puedas HTTPS, que encripta la comunicación entre el cliente y el servidor.
La creación de un servicio web RESTful en Laravel puede ser un proceso bastante sencillo gracias a la estructura y las herramientas que proporciona este framework de PHP. Utilizaremos el mismo ejemplo de la gestión de canciones.
Paso 1: Creación de un nuevo proyecto de Laravel y configuración inicial
Para empezar, debes tener instalado Composer, la herramienta para la gestión de dependencias en PHP. Luego, puedes crear un nuevo proyecto de Laravel ejecutando el siguiente comando en tu terminal:
Después de crear el proyecto, necesitarás instalar y configurar los paquetes y las configuraciones iniciales necesarias para que puedas comenzar a trabajar en tu API. Para ello, entra en la carpeta del proyecto recién creado y usa el comando php artisan install:api, que configura automáticamente la aplicación con todo lo necesario para desarrollar una API:
php artisan install:api
Paso 2: Creación y configuración de la base de datos
Primero, crea una base de datos para almacenar la información de las canciones. Para ello, utiliza phpMyAdmin, que se incluye con XAMPP, y crea una base de datos llamada laravel_canciones_db.
A continuación, debes configurar la conexión a la base de datos. Esto se hace en el archivo .env que se encuentra en la raíz del proyecto:
Luego, debes ejecutar las migraciones para crear la tabla canciones. Primero, crea unamigración con el comando:
php artisan make:migration create_canciones_table
Esto creará una nueva migración en la carpeta database/migrations. En dicho archivo, debes definir la estructura de la tabla:
public function up()
{
Schema::create('canciones', function (Blueprint $table) {
$table->id();
$table->string('titulo');
$table->string('artista');
$table->string('genero');
$table->timestamps();
});
}
Luego, ejecuta las migraciones con el comando:
php artisan migrate:fresh
Con migrate:fresh se restablece la base de datos eliminando todas las tablas y aplicando nuevamente las migraciones. Si lo deseas, puedes usar solo migrate que ejecuta las migraciones pendientes sin afectar las tablas existentes.
Paso 3: Crear el modelo y el controlador
En Laravel, los modelos se utilizan para interactuar con la base de datos. Puedes crear un modelo para la tabla canciones con el siguiente comando:
php artisan make:model Cancion
Esto generará un modelo en la carpeta app/Models. Asegúrate de que Cancion.php se vea así:
<?php
namespace App\Models;
use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;
class Cancion extends Model
{
use HasFactory;
protected $table = 'canciones';
protected $fillable = ['titulo', 'artista', 'genero'];
}
Aquí, la propiedad $fillable especifica los campos que Laravel puede llenar automáticamente cuando creas o actualizas canciones y la propiedad $table especifica el nombre de la tabla en la base de datos correspondiente a este modelo. En este caso, el nombre de la tabla es canciones.
A continuación, para manejar las solicitudes HTTP, puedes crear un controlador. Para generar rápidamente un controlador de recursos API, ejecuta el comando make:controller utilizando el parámetro --api:
Esto generará un controlador en la carpeta app/Http/Controllers. A continuación, en CancionController.php, debes definir los métodos para manejar las operaciones CRUD:
<?php
namespace App\Http\Controllers;
use Illuminate\Http\Request;
use App\Models\Cancion;
class CancionController extends Controller
{
public function index()
{
return Cancion::all();
}
public function store(Request $request)
{
$cancion = Cancion::create($request->all());
return response()->json($cancion, 201);
}
public function show(string $id)
{
return Cancion::find($id);
}
public function update(Request $request, string $id)
{
$cancion = Cancion::findOrFail($id);
$cancion->update($request->all());
return response()->json($cancion, 200);
}
public function destroy(string $id)
{
Cancion::findOrFail($id)->delete();
return response('Deleted Successfully', 200);
}
}
Este código define un controlador en Laravel para el modelo llamado Cancion. Proporciona métodos para manejar operaciones de CRUD para el modelo. Dichos métodos son: index() que muestra todas las canciones, store() que crea una nueva canción, show() que muestra una canción específica, update() que actualiza una canción existente y destroy() que elimina una canción. El código de estado HTTP 201 indica éxito en la creación de recursos, mientras que el código de estado HTTP 200 se utiliza para indicar éxito en las operaciones de actualización y eliminación.
Ten en cuenta que este controlador no tiene manejo de errores. En una aplicación real, deberías agregar manejo de errores para casos en los que, por ejemplo, se intenta buscar o eliminar una canción que no exista.
Paso 4: Definir las rutas
Para definir las rutas de nuestro servicio web, la mejor opción es usar Route::apiResource en el archivo routes/api.php. Las rutas que se encuentran en routes/api.php están diseñadas para endpoints de API, son sin estado (stateless), utilizan el middleware api, devuelven respuestas en formato JSON y aplican limitación de tasa. El método Route::apiResource declara automáticamente las rutas para todas las operaciones CRUD, excluyendo aquellas que presentan plantillas HTML, como create y edit, que sí están presentes en Route::resource.
Para definir las rutas en nuestra API, añade al final de routes/api.php el siguiente código:
use App\Http\Controllers\CancionController;
Route::apiResource('canciones', CancionController::class);
Esto crea las rutas necesarias para todas las operaciones CRUD en el controlador CancionController.
Paso 5: Probar el servicio web API HTTP RESTful
Antes de probar el servicio web, asegúrate de que tu aplicación Laravel esté en funcionamiento en el servidor local (http://localhost:8000) mediante php artisan serve. A continuación, puedes probar el servicio web utilizando herramientas como HTTPie. Aquí se presentan algunos ejemplos de solicitudes HTTP que puedes realizar con dicha herramienta.
Para agregar tres canciones, utiliza el método POST a la ruta api/canciones de tu aplicación Laravel para añadir dicha información a la base de datos:
http POST http://localhost:8000/api/canciones titulo='Shape of You' artista='Ed Sheeran' genero='Pop';
http POST http://localhost:8000/api/canciones titulo='Billie Jean' artista='Michael Jackson' genero='Pop';
http POST http://localhost:8000/api/canciones titulo='Hotel California' artista='Eagles' genero='Rock';
Aunque también se podría utilizar un array para añadir las tres canciones de una vez, en este ejemplo se optó por hacerlo de manera individual para facilitar la comprensión del funcionamiento del servicio web con Laravel. Además, utilizar un array para agregar las canciones requeriría una implementación más extensa en los métodos store, y update si queremos actualizar masivamente, del controlador CancionController.
Para ver todas las canciones, puedes hacer una solicitud GET a la ruta api/canciones de tu aplicación Laravel que devolverá todas las canciones existentes en la base de datos:
http GET http://localhost:8000/api/canciones
A continuación, para actualizar una canción, puedes utilizar el método PUT o PATCH en una solicitud HTTP:
http PUT http://localhost:8000/api/canciones/2 titulo='Smile' artista='Katy Perry' genero='Pop'
Para ver una canción específica, puedes hacer una solicitud GET a la ruta correspondiente en tu servicio web pasando el ID, por ejemplo 2, de la canción que deseas obtener:
http GET http://localhost:8000/api/canciones/2
Para eliminar la canción con ID 3, puedes utilizar el método DELETE en una solicitud HTTP:
http DELETE http://localhost:8000/api/canciones/3
Si has llegado a este punto del apartado correctamente, ya has creado un servicio web HTTP API RESTful básico en Laravel y lo has consumido. Sin embargo, recuerda, en una aplicación real, seguramente necesitarías agregar autenticación, validación de datos, manejo de errores y otras características.
HTTP (Hypertext Transfer Protocol) es un protocolo de comunicación utilizado para la transferencia de datos en la World Wide Web. Permite la solicitud y entrega de recursos, como páginas web y archivos, entre clientes y servidores a través de internet de manera segura y eficiente.
En la presente unidad de trabajo, se utilizan imágenes procedentes de Unsplash exceptuando la imagen con licencia CC0 1.0extraída de Wikipedia en el apartado 2.1.
Unsplash concede una licencia irrevocable, no exclusiva y de alcance mundial para descargar, copiar, modificar, distribuir, ejecutar y utilizar las fotografías disponibles en su plataforma sin costo alguno, incluso para fines comerciales, sin requerir permiso ni atribución al fotógrafo o a Unsplash. No obstante, esta licencia no permite recopilar fotografías de Unsplash con el propósito de replicar un servicio similar o competidor.
Materiales desarrollados inicialmente por el Ministerio de Educación, Cultura y Deporte y actualizados por el profesorado de la Junta de Andalucía bajo licencia Creative Commons BY-NC-SA.
Antes de cualquier uso leer detenidamente el siguenteAviso legal
Ubicación: 5.3 Mejora (tipo 2): * Actualización de 5.3 de implementación de un servicio web con Laravel ya que en su última versión es necesario realizar configuraciones previas.
* Renombramiento de imágenes para tenerlo más organizado.
* Archivo SCORM generado con la nueva versión estándar para GestionaFP: eXeLearning 2.8.1.
Versión: 02.00.00
Fecha de actualización: 02/06/23
Autoría: Manuel Ignacio López Quintero
Ubicación: No especificada. Mejora (tipo 1): Actualizado los contenidos.
Ubicación: Varios apartados Mejora (tipo 3):
Esta unidad 5 se convertiría en la nueva unidad 6.
Modificar el apartado 1 y separar la información teórica sobre “servicios web” de SOAP, y añadir a REST como arquitectura software para diseño de servicios web.
El apartado 1 tiene un ejemplo de descriptor de archivo WSDL que debería de adaptarse para el mismo servicio web que luego se desarrolla en los apartados 2.5-2.8), para que así haya una continuidad. El apartado 2 desarrolla un ejemplo con un servicio web SOAP que ya no funciona (http://www.webservicex.net/ws/WSDetails.aspx?CATID=2&WSID=10). El problema es que no es solo cambiar un enlace, es cambiar todos los ejemplos que dependen de ese descriptor WSDL, que son muchísimos. Además hay vídeos que no funcionan y que explican contenidos incluidos en los materiales. Por otro lado, el ejemplo de los apartados de 2.5 a 2.8 no funcionan del todo bien, deberían continuar el ejemplo de los apartados 1-4-1.9 para dar cierta continuidad. La solución para esto es modificar el apartado 2 entero, borrando lo que hay y haciéndolo de nuevo, partiendo de un ejemplo en el que se desarrolla un servicio web SOAP (primera parte) y se consume un servicio WEB SOAP (segunda parte).
Faltaría por añadir dos apartados 3 y 4. En el apartado 3 se explicaría como crear un servicio web RESTful (p.ej. con laravel) y a describirlo usando OpenAPI (sintaxis de YAML). En el apartado 4 se explicaría como consumir un servicio web RESTful (con cURL por ejemplo). Por otro lado, de cara a cumplir con el apartado f del RA 7, es necesario explicar como usar una herramienta como postman, para verificar el funcionamiento del servicio web. Esto iría en el apartado 4 o en un nuevo apartado 5).
Por último, habría que modificar los apartados 1 y 1.1, para incluir servicios web tipo REST y mejorar la redacción, el alumnado no termina de entender para qué se hacen o implementan los servicios web.
Ubicación: No especificada. Mejora (Mapa conceptual): Actualizado el mapa conceptual.
Ubicación: No especificada. Mejora (Orientaciones del alumnado): Actualizadas las orentaciones del alumnado
Versión: 01.01.00
Fecha de actualización: 16/02/15
Autoría: Carlos Ríos Ruiz
Apartado 2.3: Añadido enlace y explicación para el uso de la herramienta wsdl2php de forma online.
Breve modificación del ejercicio resuelto. Actualizado el recurso de la solución: DWES06_CONT_R18c_Ejercicio_resuelto.php
