#API REST

Hola,

A modo de ejercicio, estoy intentando desarrollar una producción que permita importar datos al UCR desde un sandbox que provee datos FHIR R4 alojado en Logica Health, para ello necesitaría implementar un servicio que se conecte, bajo demanda, al servidor FHIR e importe la totalidad de los registros, inicialmente, y a posterior solo las novedades. Lamentablemente por ahora no pude desarrollarlo debido a mi falta de conocimiento y la poca documentación que encontré al respecto.

¡Hola Comunidad!

Una función útil de nuestra estructura REST es la capacidad que tienen las clases de Dispatch para identificar los prefijos de una solicitud y redireccionarlos a otra clase de Dispatch. Este enfoque permite mejorar el orden y la lectura del código, permite mantener separadas las versiones de una interfaz fácilmente y ofrece una forma de proteger llamadas a APIs a las que solo ciertos usuarios podrán acceder.

¡Sí sí! ¡Adelante! No os habéis equivocado, estáis en vuestra querida Comunidad de Desarrolladores de InterSystems en español.

Os preguntaréis a qué viene el título de este artículo, pues muy sencillo, hoy estamos aquí reunidos para honrar al Inquisidor y elogiar la gran labor desempeñada por el mismo.

¡Hola desarrolladores! Quería compartir hoy un ejemplo muy interesante por parte de Tani Frankel. Se trata de una aplicación sencilla sobre la utilidad SystemPerfomance.

Repasando nuestra documentación sobre la rutina de monitorización ^SystemPerformance (conocida como ^pButtons en versiones anteriores a IRIS), un cliente me dijo «Entiendo todo esto pero ojalá fuese más simple, más sencillo para definir perfiles y gestionarlos, etc.».

Entonces pensé que sería interesante como ejercicio facilitar una pequeña interfaz para hacer esas tareas más sencillas.

El primer paso era envolver en una API basada en clases la rutina actual de ^SystemPerformance.

Resulta que un día estás trabajando en Widgets Direct, distribuidor líder de widgets y accesorios, y tu jefe te pide que desarrolles un nuevo portal dedicado a los clientes, el cual permita que la cartera de clientes tenga acceso a la siguiente generación de widgets... y él quiere que utilices Angular 1.x para comunicarte con el servidor Caché del departamento.

Solamente hay un problema: Nunca has utilizado Angular y no sabes cómo hacer que se comunique con Caché (o IRIS).

En esta guía veremos cómo se realiza todo el proceso de configuración de un conjunto de subsistemas en Angular, el cual se comunica con un backend de Caché utilizando JSON para llamar un API REST.

Hace poco, tuve que generar una especificación en Swagger a partir de clases persistentes y en serie, así que ahora publico el código (no está completo, aún queda resolver las especificaciones de la aplicación, pero es un comienzo).

El código está disponible aquí.

Supongamos que tenemos estas clases:

La aplicación Carbon Footprint Counter utiliza el GHG Protocol para medir las emisiones de carbono en las empresas. El Protocolo de Gases de Efecto Invernadero (GHG Protocol) establece marcos estandarizados globales integrales para medir y gestionar las emisiones de gases de efecto invernadero (GHG) de las operaciones del sector público y privado, las cadenas de valor y las acciones de mitigación.

Sobre la base de una asociación de 20 años entre el Instituto de Recursos Mundiales (WRI) y el Consejo Empresarial Mundial para el Desarrollo Sostenible (WBCSD), el GHG Protocol trabaja con gobiernos, asociaciones industriales, ONGs, empresas y otras organizaciones. (fuente: https://ghgprotocol.org/about-us).

La aplicación Carbon Footprint Counter utiliza InterSystems IRIS para implementar APIs REST y la base de datos SQL para administrar el inventario de emisiones de carbono en las empresas. La interfaz es Angular 12 con el framework PrimeNG (líder de código abierto para Angular).

En vuestra Producción de Interoperabilidad, siempre podíais tener una Business Operation (BO) que fuera un cliente HTTP y que utilizara OAuth 2.0 para la autenticación. Sin embargo, teníais que personalizar la BO para esta metodología de autenticación. Desde la versión 2024.3, que se lanzó recientemente, hay una nueva capacidad que proporciona nuevos ajustes para gestionar esto de forma más sencilla.

En este artículo me gustaría presentar el proyecto RESTForms: back-end genérico REST API para aplicaciones web modernas.

La idea detrás del proyecto es simple: después de escribir varias API REST, me di cuenta de que, en general, la API REST consta de dos partes:

• Trabajar con clases persistentes.
• Lógica de negocio personalizada

Y, si bien tendrá que escribir su propia lógica de negocio personalizada, RESTForms proporciona todo lo relacionado con el trabajo con clases persistentes desde el primer momento.
Casos de uso

• Ya tiene un modelo de datos en Caché y desea exponer parte (o toda) de la información en forma de API REST
• Está desarrollando una nueva aplicación Caché y desea proporcionar una API REST

¡Bienvenidos a todos!

En este breve artículo quería presentar un ejemplo de uso que seguramente a muchos de los que trabajéis con IRIS como backend de vuestras aplicaciones web os hayáis encontrado en más de una ocasión y sería el de la necesidad de enviar desde el frontend un archivo a vuestro servidor.

¡Hola a tod@s!

El objetivo de este artículo es describir cómo emplear una BBDD como ElasticSearch, para permitirnos monitorizar nuestros proyectos.

Bajo el escenario que ya tenemos una API REST, funcionando, y queremos incorporarla a una producción para contar con trazabilidad y todas las ventajas que ofrece IRIS para interoperar, dejo este artículo para cambiar una API existente que responde un JSON, para responder el mismo JSON pero dejando sus trazas en una producción de la misma instancia.

Lo primero, ya contamos con una aplicación creada, llamada /restapi y que tiene como DispatchClass: Testing.REST.ApiDisp (o la clase que tenemos en nuestra instancia).

Hasta ahora, estamos familiarizados con cómo implementar una API básica de REST en Caché y aquí hay una buena documentación al respecto: REST en Caché.

Sin embargo, una pregunta que surge de vez en cuando es: ¿Cómo puedo hacer que un parámetro en mi URL REST sea opcional?

En la primera parte de esta serie de artículos, hablamos sobre cómo leer un fragmento "grande" de datos del contenido sin procesar de un método HTTP POST y guardarlo en una base de datos como una propiedad de flujo de una clase. Ahora veremos cómo guardar esos datos y metadatos en formato JSON.

Desafortunadamente, Advanced REST Client no permite configurar objetos JSON con datos binarios como valor de una clave (o quizá simplemente no he descubierto cómo hacerlo), así que decidí escribir un cliente simple en ObjectScript para enviar datos al servidor.

Creé una nueva clase llamada RestTransfer.Client y le añadí los parámetros Server = "localhost" y Port = 52773 para describir mi servidor web. Y creé un método de clases GetLink en el que creo una nueva instancia de la clase %Net.HttpRequest y establezco sus propiedades con los parámetros mencionados anteriormente.