¿Qué es un servicio web?

Un servicio web es una interfaz a través de la cual las aplicaciones intercambian datos o invocan funciones por la red. Un sitio web está pensado sobre todo para que lo lean y lo usen personas; un servicio web expone un contrato dirigido a clientes de software. Un mismo producto puede ofrecer ambas cosas. Muchos servicios usan HTTP y JSON, pero el término abarca también otros protocolos y formatos de datos.

Cómo funcionan la solicitud y la respuesta

El cliente envía una solicitud a un endpoint definido con un método, unos parámetros y, si hace falta, sus credenciales. El servicio valida la solicitud, realiza la operación y devuelve una respuesta. En las API HTTP, los códigos de estado distinguen los resultados a grandes rasgos: una respuesta correcta, un problema del cliente, como una entrada no válida, o un fallo del servidor. El cuerpo de la respuesta suele aportar más detalle en un formato documentado.

Un contrato claro describe las rutas, los métodos, los campos, los tipos, la autenticación, los límites de uso y las condiciones de error. Gracias a él, los clientes pueden desarrollarse de forma independiente. El versionado es importante, porque cambiar un campo o su interpretación puede romper aplicaciones existentes aunque la dirección del endpoint siga siendo la misma. Mantenga la compatibilidad con versiones anteriores cuando la haya prometido y anuncie los periodos de retirada.

Estilos de interfaz habituales

REST es un estilo de arquitectura, no un formato concreto de transmisión. Las API HTTP que se definen como RESTful suelen representar los recursos con URL y usar métodos como GET para leer y POST o PUT para modificar. Una petición GET no debería provocar un cambio de estado duradero, ya que los clientes y los intermediarios pueden repetirla o guardarla en caché. SOAP, presente en muchos sistemas empresariales, utiliza mensajes XML estructurados y descripciones formales del servicio.

GraphQL permite a los clientes pedir una selección concreta de campos a través de un esquema, a menudo sobre HTTP. Puede reducir la transferencia de datos innecesarios, pero complica el control del coste de las consultas, la autorización y la caché. Los webhooks invierten el patrón habitual de sondeo: un servicio llama a un endpoint registrado cuando ocurre un evento. Necesitan autenticar al remitente, gestionar los reintentos y protegerse frente a entregas duplicadas. Ninguno de estos enfoques es el mejor para todo.

Seguridad y privacidad

Use HTTPS para proteger los datos en tránsito y verifique el certificado del servidor. Autentique a quien llama con un esquema de credenciales adecuado y autorice por separado cada operación y cada objeto. Un token válido solo acredita lo que permite su alcance; no convierte en segura cualquier entrada. Valide el tamaño y el tipo de las solicitudes, no exponga datos privados en los mensajes de error y fije límites contra el abuso.

Los secretos no deben aparecer en URL públicas, en el código del lado del cliente ni en los registros. Si una credencial queda expuesta, renuévela; limite su alcance y use credenciales distintas para producción y para pruebas. En las API que aceptan una URL de devolución de llamada (callback), valide los destinos para impedir solicitudes hacia redes internas. Documente qué datos personales se devuelven y conserve solo los imprescindibles.

Fiabilidad y rendimiento

Las redes fallan, así que los clientes necesitan tiempos de espera, reintentos acotados y una gestión clara de los fallos parciales. Una lectura puede reintentarse cuando es seguro hacerlo; reintentar un pago u otra modificación exige un diseño idempotente para evitar duplicados. La paginación pone límite a los conjuntos de resultados grandes. La caché puede aliviar la carga cuando los datos públicos son estables, mientras que las respuestas privadas o que cambian rápido requieren una política de caché cuidadosa.

Los operadores deben medir la latencia, la tasa de errores y la disponibilidad desde la ruta real del cliente. Un servidor puede devolver HTTP 200 con datos incompletos o inservibles, así que conviene vigilar también los resultados de negocio esperados. Los límites de uso protegen el servicio, pero deben comunicarse de forma predecible. Si el servicio es importante para sus usuarios, ofrezca una página de estado o un canal de soporte para los incidentes.

Cómo elegir o crear un servicio

Parta de la tarea del usuario y del contrato de datos, y elija después un estilo de interfaz que los clientes puedan implementar y el equipo pueda mantener. Pruebe las respuestas normales, las entradas mal formadas, las credenciales caducadas, los permisos, la paginación y los tiempos de espera. Mantenga los ejemplos al día y muestre errores concretos. Al integrar un servicio de terceros, lea sus límites de uso, su política de datos y sus avisos de cambios: por cómodo que sea un endpoint, sigue siendo una dependencia que puede fallar.