Servicios Web

Actualizada el Programación

Los Servicios Web se pueden implementar mediante dos tecnologías: SOAP (Simple Object Access Protocol) y REST (REpresentational State Transfer).

SOAP

SOAP es un protocolo de acceso a servicios web que define un protocolo de comunicación basado en una especificación de intercambio de mensajes XML. WSDL (Web Services Description Language) permite definir un servicio web basado en SOAP.

SOAP se ha utilizado ampliamente como el estándar de facto para construir servicios web, pero su complejidad ha llevado a emplear REST en su lugar.

REST

REST describe un conjunto de principios de arquitectura por los que los datos se pueden transmitir sobre Internet. Hoy en día es una arquitectura muy popular para crear APIs.

Comparación SOAP y REST

SOAP REST
Concepto Ofrece los datos como servicios (verbos + nombres). Ofrece los datos como recursos (nombres).
Por ejemplo, getUser. Por ejemplo, user.
Ventajas Sigue un enfoque empresarial formal. Sigue la filosofía de la Web abierta.
Funciona sobre cualquier protocolo de comunicación, incluso de forma asíncrona. Es relativamente fácil de implementar y mantener.
La información sobre los objetos se comunica a los clientes. La comunicación no está controlada por una sola entidad.
Tanto seguridad como autorización son parte del protocolo. Separa claramente las implementaciones del cliente y del servidor.
Se puede describir completamente usando WSDL. La información se puede almacenar por el cliente para evitar múltiples llamadas.
Se pueden devolver datos en múltiples formatos (JSON, XML, etc.)
Inconve- nientes Gasta mucho ancho de banda con la comunicación de metadatos. Solo funciona encima del protocolo HTTP.
Difícil de implementar e impopular entre desarrolladores Web y móvil. Difícil de hace cumplir la autorización y la seguridad.
Cuándo usarlo Cuando los clientes necesitan acceder a objetos disponibles en los servidores. Cuando clientes y servidores operan en un entorno Web.
Cuando hay que cumplir un contrato formal entre cliente y servidor. Cuando no es necesario comunicar información sobre los objetos al cliente.
Cuándo no usarlo Cuando se quiera que la mayoría de desarrolladores puedan usar la API de forma sencilla. Cuando haya que cumplir un contrato estricto entre cliente y servidor.
Cuando el ancho de banda sea limitado. Al realizar transacciones que impliquen múltiples llamadas.
Casos de uso Servicios financieros. Servicios de redes sociales.
Pasarelas de pago. Redes sociales.
Servicios de telecomunicaciones. Servicios Web.
Servicios móviles.
Conclusión Usar SOAP para gestionar operaciones transaccionales siempre que todos los posibles clientes están de acuerdo con esta tecnología. Usar REST para adoptar APIs a gran escala o si la API tiene como objetivo aplicaciones móviles.

Referencias

  • Dzone
  • Da14
  • JavaScript in Plain English
  • SOA Governance in Action. REST and Web Service architectures (2012). Jos Dirksen. Manning
  • Applied SOA. Service-Oriented Architecture and Design Strategies(2008). Mike Rosen, Boris Lublinsky, Kevin T. Smith, Marc J. Balcer. Wiley Publishing, Inc.
  • Pro RESTful APIs (2017). Sanjay Patni. Apress

Publicaciones Similares

  • Herramientas de seguridad

    Porroberto

    Herramientas de proxy BurpSuite Pro OWASP ZAP HackBar TamperData Herramientas de escaneo de servicios Nmap Masscan Herramientas de fuerza bruta Hydra Medusa Patator Análisis de metadatos FOCA Metagoofil Exiftool RastLeak Fuzzing directorios Dirb/dirbuster Dirsearch Cansina gobuster Wfuzz Dirhunt ffuf Análisis SSL/TLS Testssl SSLScan Enumeración subdominios Aquatone Sublist3r DorkGo0 reconFTW GooFuzz CTFR Análisis configuración Nikto Lynis

  • Protección de datos en entornos de contenedores

    Porroberto

    Introducción a los Contenedores Un contenedor es una unidad de software que incluye todo lo necesario para que una aplicación funcione: el código, las bibliotecas, las dependencias y las configuraciones necesarias. Los contenedores son importantes por: Portabilidad: Los contenedores permiten que las aplicaciones se ejecuten de manera consistente en diferentes entornos. Esto es especialmente útil…

  • n8n

    Porroberto

    ¿Qué es n8n? n8n (pronunciado «n-eight-n») es una herramienta de automatización de flujos de trabajo de código abierto que permite conectar aplicaciones, servicios y tareas de forma visual, sin necesidad de escribir código (aunque es altamente personalizable con JavaScript si se desea). El nombre n8n viene de “node-based workflow automation tool”, con una estética similar…

  • Buenas prácticas

    Porroberto

    Usar una estructura de proyecto estándar src ├── main │ ├── java Application/Library sources │ ├── resources Application/Library resources │ ├── filters Resource filter files │ └── webapp Web application sources │ └── test ├── java Test sources ├── resources Test resources         └── filters              …

  • Docker – Habilitar acceso remoto a la api

    Porroberto

    Lo utilizo con homepage Pasos Editar /lib/systemd/system/docker.service Modificar la línea: ExecStart=/usr/bin/docker daemon -H fd:// -H tcp://0.0.0.0:2375 Recargar la configuración y reiniciar el demonio: sudo systemctl daemon-reload sudo systemctl restart docker.service

  • Historia de las redes neuronales

    Porroberto

    1958 – Perceptrón 1965 – Perceptrón multicapa 1980’s Neuronas Sigmoidales Redes Feedforward Retropropagación 1989 – Convolutional neural networks (CNN) / Recurent neural networks (RNN) 1997 – Long short term memory (LSTM) 2006 – Deep Belief Networks (DBN): Nace deep learning Restricted Boltzmann Machine Encoder / Decoder = Auto-encoder 2014 – Generative Adversarial Networks (GAN)