#REST API

The Widgets Direct sample application highlights many aspects of how to use InterSystems technologies to build a modern web application. Features include:

Developing a Full-Stack JavaScript web app with Caché requires you to bring together the right building blocks. In the previous part, we created a basic front-end React application. In the second part of this article series I will show how to choose the right back-end technology for your application. You will see Caché allows you to use many different approaches to link your front-end to your Caché server, depending on your application's needs. In this part we will set up a back-end with Node.js/QEWD and CSP/REST. In the next part we will enhance our basic web app and connect it to Caché using these technologies.

Setting the Scene

Suppose you have the following 2 persistent classes that are both JSON-enabled (i.e. extends %JSON.Adaptor or %pkg.isc.rest.model.adaptor)

So far, we have covered how to use ObjectScript to manage users, roles, resources, and applications. There are a few other classes in this package that work similarly to the ones mentioned above. However, these four classes are the ones everyone will have to use to manage their application security.

By default InterSystems IRIS expose your endpoints using http, but can be necessary run https from your dev env and/or get public internet access to your app. You can buy or get a certificate and config a gateway, spending many hours or use a great public service called ngrok. Follow the steps:

1 - Run your app, I will use FHIR template as sample, see:

1.1 download the app: git clone https://github.com/intersystems-community/iris-fhir-template.git

This series of articles aims to address the following topics:

• Creation of a web application based on REST pages;
• Overview of some tools for tracing (debugging) HTTP requests;
• Switching from hyperevents to... hyperevents;
• Integration with jQuery File Upload;
• Conversion of JSON from the {id:1,parentId:1} format to the {id:1,children:[{}]} format for tree visualization;
• Integration with jQuery EasyUI (using datagrid and tree as examples);
• Other topics.

A few weeks ago I posted an announcement about a JavaScript-based interface for our mg_web WebServer interfacing addon module. mg_web isn't just restricted to use by JavaScript developers though. Many readers will be ObjectScript developers who are more used to using CSP as their web gateway. Some may even have much older legacy WebLink-based applications (and be wondering how to support them given that IRIS does not support WebLink).

In this article, we will explore the development of an IRIS client for consuming RESTful API services that have been developed to the OData API standard.

We will be exploring a number of built-in IRIS libraries for making HTTP requests, reading and writing to JSON payloads, and seeing how we can use them in combination to build a generic client adaptor for OData. We will also explore the new JSON adapter for deserializing JSON into persistent objects.

In your Interoperability Production you could always have a Business Operation that is an HTTP client, that uses OAuth 2.0 for authentication, but you had to customize the Operation for this authentication methodology. Since v2024.3, which was lately released, there is a new capability, providing new settings, to handle this more easily.

Hello.

The idea of this post is to introduce Frontier: An abstraction layer that allows Rapid REST development.

REQUIREMENTS:

• Caché 2016.2 or higher.
• Frontier.

Why?

Have you ever found yourself dealing with repetitive tasks like mounting objects, serializing them and eventually handling multiple errors for multiple cases? Frontier can boost your development by making you focus on what really matters: your application.

Frontier is made to stop you from WRITE'ing by instead forcing your methods to return values.
It's designed to make you code clean, and you'll see the why pretty soon.

This is the Part 1, where you'll learn he basics about how to work with Frontier. That means at the end of this part you should be capable of

creating GET requests without difficulties. Since this also serves as a way to introduce the framework, I'll be calling this part: Core concepts.

Hi Community,

In the first part, we describe all packages, used libraries and REST services.

Now, I would like to add some details about converter and validator services.

By default, OpenAPI-Suite sends an HTTP request to converter.swagger.io if the specification version is less than 3.0 and another HTTP request to validator.swagger.io to simplify the structure of the specification document.

Although the usage of online utilities is convenient, in some cases it could be better to have our own instance of the converter and validator. For example, if OpenAPI-Suite is provided on a server in an organisation for ObjectScript developers, it may be preferable to avoid requests to external services (privacy, avoid request rate limits).

Just run:

docker run -d -p 8085:8080 --name swagger-converter swaggerapi/swagger-converter:latest
docker run -d -p 8086:8080 --name swagger-validator-v2 swaggerapi/swagger-validator-v2:latest

Hi guys.

Recently, I get interest in FHIR in order to run for the IRIS for Health FHIR
contest. As a beginner on this topic, I've heard somewhat about it, but I didn't know how complex and powerful was FHIR. As pointed out by @Henrique.GonçalvesDias here, you can model several aspects of the patient history and other related entities.

IRIS Interoperability Productions formerly known as Ensemble are fun to work with. Yes, I really think my work is fun. I have seen File Passthrough Services and File Passthrough Operations come in handy. At one point we placed test messages in files, then we utilized a File Passthrough Service with Inbound File Adapter to send the contents of the file as a Stream to a File Passthrough Operation with Outbound TCP Adapter.

Developing a Full-Stack JavaScript web app with Caché requires you to bring together the right building blocks. In this third part of this article series I will show how to link our React app to our three back-ends we created in part 2.