#SOAP

¡Hola Comunidad!

Como explicó Rob en un artículo anterior, la interfaz Node.js de Caché permite crear Servicios Web y Servicios REST utilizando el framework modular framework EWD 3.

Por defecto, estos servicios devuelven una respuesta JSON con Content-Type: application / json y el cuerpo de respuesta contiene el JSON que devuelve utilizando el método finished(), por lo que:

finished({ test: 'test response' });

devuelve

{ "test": "test response" }

con un content-type HTTP de application/json

¡Hola Comunidad!

En este artículo hablaré sobre las pruebas y la depuración de las aplicaciones web de Caché (principalmente REST) con herramientas externas. La segunda parte trata sobre las herramientas de Caché.

Usted escribió el código del lado del servidor y quiere probarlo con un cliente, o ya tiene una aplicación web pero no funciona. Aquí es donde entra la depuración. En este artículo abarcaré desde las herramientas más fáciles de utilizar (el navegador), hasta las más completas (el analizador de paquetes), pero primero conversemos un poco sobre los errores más comunes y cómo pueden resolverse.

En el primer artículo empecé a analizar RESTForms - REST API para tus clases persistentes y hablamos sobre las características básicas. Ahora, me gustaría hablar sobre las características avanzadas, principalmente las capacidades de consultas:

• Consultas básicas
• Consultar argumentos
• Consultas personalizadas

Consultas

Las consultas pueden obtener segmentos de datos, criterios en criterios arbitrarios. Hay dos tipos de consulta en RESTForms:

• Las consultas básicas funcionan para todas las clases RESTForms una vez definidas y solo difieren en la lista de campos
• Las consultas personalizadas solo funcionan para las clases en las que están especificadas y disponibles, pero el desarrollador tiene acceso completo al texto de la consulta

Cuando se llama a los servicios web, existen varios escenarios para los Business Operation, que actúan juntos para controlar lo que sucederá cuando no se obtenga una respuesta en el tiempo deseado. (Esto también es importante, por ejemplo, en el caso de una solicitud HTTP simple que no pertenezca a los servicios SOAP).

InterSystems API Manager (IAM) es una nueva función de InterSystems IRIS que permite monitorizar, controlar y dirigir el tráfico hacia y desde las APIs web dentro de su infraestructura de TI. Si te perdiste el anuncio de su lanzamiento, puedes leerlo aquí. También puedes consultar este otro artículo.

En esta publicación, utilizaremos InterSystems API Manager para balancear la carga de una API.

En nuestro caso, tenemos 2 instancias de InterSystems IRIS con /api/atelier API REST que queremos publicar para nuestros clientes.

Hay muchas razones diferentes por las que podríamos querer hacer eso, como:

• Equilibrio de carga para distribuir la carga de trabajo entre los servidores
• Implementación azul-verde: tenemos dos servidores, uno "prod", otro "dev" y es posible que queramos cambiar entre ellos
• Implementación de Canary: podríamos publicar la nueva versión solo en un servidor y mover el 1% de los clientes allí
• Configuración de alta disponibilidad
• etc.

Los WebSockets, como tecnología de comunicación, están ganando una importancia cada vez mayor.
En el namespace SAMPLES puedes encontrar un buen ejemplo para ejecutar un WebSocket Server.
También hay un útil ejemplo para un Browser Client, pero sigue estando en el navegador.

La cuestión es:
¿Cómo consumir la salida de un WebSocket Server en tu aplicación?