Introduction

A REST API (Representational State Transfer) is an interface that allows different applications to communicate with each other through the HTTP protocol, using standard operations such as GET, POST, PUT, and DELETE. REST APIs are widely used in software development to expose services accessible by other applications, enabling integration between different systems.

However, to ensure that APIs are easy to understand and use, good documentation is essential. This is where OpenAPI comes in.

OpenAPI is a standard for describing RESTful APIs.

Monitoring your IRIS deployment is crucial. With the deprecation of System Alert and Monitoring (SAM), a modern, scalable solution is necessary for real-time insights, early issue detection, and operational efficiency. This guide covers setting up Prometheus and Grafana in Kubernetes to monitor InterSystems IRIS effectively. 

This guide assumes you already have an IRIS cluster deployed using the InterSystems Kubernetes Operator (IKO), which simplifies deployment, integration and mangement.

Why Prometheus and Grafana?

InterSystems IRIS 2019.1 has been out for a while and I would like to cover some enhancements for handling JSON which might have gone unnoticed. Dealing with JSON as a serialization format is an important part of building modern applications, especially when you interact with REST endpoints.

Hi Community,

I would like to present my last package OpenAPI-Suite, this is a set of tools to generate ObjectScript code from an OpenAPI specification version 3.0.  In short, these packages allow to: 

• Generate server-side class.  It’s pretty similar to the generated code by ^%REST but the added value is the version 3.0 support.
• Generate HTTP client classes.
• Generate client production (business services, business operation, business process, Ens.Request, Ens.Response) classes.
• A web interface to generate and download the code or generate and compile directly on the server.
• Convert specification from version 1.x, 2.x to version 3.0.

The Lo-Code Challenge

Imagine the scene.  You are working happily at Widgets Direct, the internet's premier retailer of Widgets and Widget Accessories.   Your boss has some devastating news, some customers might not be fully happy with their widgets, and we need a helpdesk application to track these complaints.   To makes things interesting, he wants this with a very small code footprint and challenges you to deliver an application in less than 150 lines of code using InterSystems IRIS.  Is this even possible?

So, one day you're working away at WidgetsDirect, the leading supplier of widget and widget accessories, when your boss asks you to develop the new customer facing portal to allow the client base to access the next generation of Widgets..... and he wants you to use Angular 1.x to read into the department's Caché server.   

There's only one problem:  You've never used Angular, and don't know how to make it talk to Caché.

As you might have heard, we just introduced the InterSystems API Manager (IAM); a new feature of the InterSystems IRIS Data Platform™, enabling you to monitor, control and govern traffic to and from web-based APIs within your IT infrastructure. In case you missed it, here is the link to the announcement.

In this article, I will show you how to set up IAM and highlight some of the many capabilities IAM allows you to leverage.

In this article I'll cover testing and debugging Caché web applications (mainly REST) with external tools. Second part covers Caché tools.

You wrote server-side code and want to test it from a client or already have a web application and it doesn't work. Here comes debugging. In this article I'll go from the easiest to use tools (browser) to the most comprehensive (packet analyzer), but first let's talk a little about most common errors and how they can be resolved.

So, one day you're working away at WidgetsDirect, the leading supplier of widget and widget accessories, when your boss asks you to develop the new customer facing portal to allow the client base to access the next generation of Widgets..... and he wants you to use Angular 1.x to read into the department's Caché server.   

There's only one problem:  You've never used Angular, and don't know how to make it talk to Caché.

Foreword

InterSystems IRIS versions 2022.2 and newer feature the ability to authenticate to a REST API using JSON web tokens (JWTs). This feature enhances security by limiting where and how often passwords transfer over the network in addition to setting an expiration time on access.

The goal of this article is to serve as a tutorial on how to implement a mock REST API using InterSystems IRIS and lock access to it behind JWTs.

NOTE I am NOT a developer. I make no claims as to the efficiency, scalability, or quality of the code samples I use in this article.

Creating REST API using InterSystems ObjectScript is very easy, but some recipes can help you into this process:

1) To create your REST API extends %CSP.REST and Go to System Administration > Security > Applications > Web Applications > Click the button Create New Web Application and set the Name, REST Dispatch Class with your package and classname and choose the Allowed Authetication Methods. See this example:

Edit Web Application

2) Configure your REST API using ZPM configuration. To do this follow this sample (watch the tag <CSPApplication>):

Over the past year or so, my team (Application Services at InterSystems - tasked with building and maintaining many of our internal applications, and providing tools and best practices for other departmental applications) has embarked on a journey toward building Angular/REST-based user interfaces to existing applications originally built using CSP and/or Zen. This has presented an interesting challenge that may be familiar to many of you - building out new REST APIs to existing data models and business logic.

In this article, I would like to talk about the spec-first approach to REST API development.

While traditional code-first REST API development goes like this:

• Writing code
• REST-enabling it
• Documenting it (as a REST API)

Spec-first follows the same steps but reverse. We start with a spec, also doubling as documentation, generate a boilerplate REST app from that and finally write some business logic.

This is advantageous because:

• You always have relevant and useful documentation for external or frontend developers who want to use your REST API
• Specification created in OAS (Swagger) can be imported into a variety of tools allowing editing, client generation, API Management, Unit Testing and automation or simplification of many other tasks
• Improved API architecture.  In code-first approach, API is developed method by method so a developer can easily lose track of the overall API  architecture, however with the spec-first developer is forced to interact with an API from the position if API consumer which usually helps with designing cleaner API architecture
• Faster development - as all boilerplate code is automatically generated you won't have to write it, all that's left is developing business logic.
• Faster feedback loops - consumers can get a view of the API immediately and they can easier offer suggestions simply by modifying the spec

Let's develop our API in a spec-first approach!

What is JWT?

JWT (JSON Web Token) is an open standard (RFC 7519) that offers a lightweight, compact, and self-contained method for securely transmitting information between two parties. It is commonly used in web applications for authentication, authorization, and information exchange.

A JWT is typically composed of three parts:

1. JOSE (JSON Object Signing and Encryption) Header
2. Payload
3. Signature

These parts are encoded in Base64Url format and concatenated with dots (.) separating them.

I'm a huge sci-fi fan, but while I'm fully onboard the Star Wars train (apologies to my fellow Trekkies!), but I've always appreciated the classic episodes of Star Trek from my childhood. The diverse crew of the USS Enterprise, each masterminding their unique roles, is a perfect metaphor for understanding AI agents and their power in projects like Facilis. So, let's embark on an intergalactic mission, leveraging AI as our ship's crew and  boldly go where no man has gone before

Introduction

The standard %Net.HttpRequest library in InterSystems IRIS is powerful and comprehensive, but it can be verbose for simple operations. Writing an HTTP request often requires several lines of code to instantiate the class, configure the server, the port, HTTPS, add headers, and finally send the request.

When testing in the terminal, this configuration quickly becomes too heavy, and usually ends up with the creation of temporary methods...

FastHTTP

or "So you just got yelled at by your boss, for sending him an unformatted Hello World webpage"

Our previous lesson ended with us serving a Message value obtained from a Caché REST service to the client, using Angular as a runtime.  While there is a lot of moving parts involved in this process, the page is not especially exciting at the moment.  Before we can start adding new features, we should take a step back and review our tools.

This tutorial is using the JSON functionality built into 2016.2+ versions of Caché.  This functionality is partially available in 2016.

In this article I would like to present the RESTForms project - generic REST API backend for modern web applications.

The idea behind the project is simple -after I wrote several REST APIs I realized that generally, REST API consists of two parts:

• Work with persistent classes
• Custom business logic

And, while you'll have to write your own custom business logic, RESTForms provides all things related to working with persistent classes right out of the box.
Use cases

• You already have a data model in Caché and you want to expose some (or all) of the information in a form of REST API
• You are developing a new Caché application and you want to provide a REST API

Healthcare interoperability is instrumental in improving patient care, decreasing healthcare provider costs, and providing a more accurate picture to providers. However, with so many different systems, data is formatted in many different ways. There are many standards that have been created to try to solve this problem, including HL7v2, HL7v3, and CDA but each one has its drawbacks.

FHIR, or Fast Healthcare Interoperability Resources, is a new format for healthcare data that aims at solving these problems.

HTTP and HTTPS with REST API

Hello

The HTTP protocol allows you to obtain resources, such as HTML documents. It is the basis of any data exchange on the Web and a client-server protocol, meaning that requests are initiated by the recipient, usually a Web browser.

REST APIs take advantage of this protocol to exchange messages between client and server. This makes REST APIs fast, lightweight, and flexible. REST APIs use the HTTP verbs GET, POST, PUT, DELETE, and others to indicate the actions they want to perform.

When we make a call to a RESt API, what actually happens is an HTTP call. The API receives this call and according to the requested verb and path, the API performs the desired action. In the case of the Iris implementation we can see this clearly in the URLMap definition area:

By now it's a commonplace how to implement a basic REST API in Caché and there is good documentation about it here: REST in Caché

A question that comes up from time to time is:

How can I make a parameter in my REST url optional?

Simply put, is it possible to create a URL map in Caché that maps a URL like this:

http://server/API/object///old

While this might look odd, this is actually a valid URL. You can read the details in RFC3986 section 3.3.

The framework provided by %CSP.Rest actually allows us to create maps that match the above URL.

Integrating frontend React applications with backend services like IRIS database via REST APIs can be a powerful way to build robust web applications. However, one common hurdle developers often encounter is the Cross-Origin Resource Sharing (CORS) issue, which can prevent the frontend from accessing resources on the backend due to security restrictions enforced by web browsers. In this article, we'll explore how to tackle CORS issues when integrating React web apps with IRIS backend services.

Creating the Schema

We start by defining a simple schema named Patients:

Class Prototype.DB.Patients Extends %Persistent [ DdlAllowed ]
{

Property Name As %String;

Property Title As %String;

Property Gender As %String;

Property DOB As %String;

Property Ethnicity As %String;
}

One of the most common kinds of integration we are asked to do is emailing. One of the most typical email services our customers use is Microsoft’s Office 365. After setting up the right configuration on the Microsoft side, we can email from IRIS with two HTTP requests. By the end of this article, we will be able to send an email with an attachment through our Microsoft 365 service!

Microsoft’s REST API, called Graph, allows you to do a lot of things within Microsoft’s various apps, and it is precisely what we will employ to send our email.

In this article, I will share the theme we presented at the Global Summit 2023, in the Tech Exchange room. Me and @Rochael.

In this article you will have access to the curated base of articles from the InterSystems Developer Community of the most relevant topics to learning InterSystems IRIS. Find top published articles ranked by Machine Learning, Embedded Python, JSON, API and REST Applications, Manage and Configure InterSystems Environments, Docker and Cloud, VSCode, SQL, Analytics/BI, Globals, Security, DevOps, Interoperability, Native API. Learn and Enjoy!

Machine Learning

Machine Learning is a mandatory technology to build advanced data analysis and automate manual activities with excellent efficiency.

My main goal of this article was to prove the use of InterSystems IRIS for Health for REST FHIR interoperability between multiple applications. In this use case, some initiating application makes a REST call to IRIS for Health (which is merely a passthrough for REST calls) to retrieve FHIR data from an Oracle Health R4 FHIR repository. Ideally, it simplifies the syntax for calling the Oracle Health APIs.

You send an HTTP request and get back an HTTP error but with an HTML error page which you didn't expect... what's happening?... 🤔

Specifically for example, perhaps you tried to READ a FHIR Resource (e.g. /Patient/123) and you get back a 404 error page, even though with other Patient IDs, you get back the Resource payload, so "the page" definitely does exist... why should you be getting a 404 error page? 🙄

There are numerous excellent tools available for testing your REST APIs, especially when they are live. Postman, various web browser extensions, and even custom ObjectScript written with %Net.HttpRequest objects can get the job done. However, it is often difficult to test just the REST API without inadvertently involving the authentication scheme, the web application configuration, or even network connectivity. Those are a lot of hoops to jump through just to test the code within your dispatch class. The good news is that if we take our time to understand the inner workings of the %CSP.REST class, we will find an alternative option suited for testing only the contents of the dispatch class. We can set up the request and response objects to invoke the methods directly.

Some time ago I got a WRC case transferred where a customer asks for the availability of a raw DEFLATE compression/decompression function built-in Caché.

When we talk about DEFLATE we need to talk about Zlib as well, since Zlib is the de-facto standard free compression/decompression library developed in the mid-90s.

Zlib works on particular DEFLATE compression/decompression algorithm and the idea of encapsulation within a wrapper (gzip, zlib, etc.).
https://en.wikipedia.org/wiki/Zlib

Recently I needed to generate a Swagger spec from persistent and serial classes, so I'm publishing my code (it's not complete - you still need to hash out the application specifics, but it's a start). It's available here.

Let's say you have these classes:

Class REST.Test.Person Extends %Persistent
{

/// Person's name.
Property Name As %String [ Required ];

/// Person's Social Security number. This is validated using pattern match.
Property SSN As %String [ Required ];

/// Person's Date of Birth.
Property DOB As %Date;

/// Person's home address. This uses an embedded object.
Property Home As Address;

/// Person's office address. This uses an embedded object.
Property Office As Address;

/// Person's spouse. This is a reference to another persistent object.
Property Spouse As Person;

/// A collection of strings representing the person's favorite colors.
Property FavoriteColors As list Of %String;

/// A collection of strings representing the person's favorite colors.
Property FavoriteNumbers As array Of %Integer;

/// Person's age.<br>
/// This is a calculated field whose value is derived from <property>DOB</property>.
Property Age As %Integer;

}

Class REST.Test.Address Extends %SerialObject
{

/// The street address.
Property Street As %String(MAXLEN = 80);

/// The city name.
Property City As %String(MAXLEN = 80);

/// The 2-letter state abbreviation.
Property State As %String(MAXLEN = 2);

/// The 5-digit U.S. Zone Improvement Plan (ZIP) code.
Property Zip As %String(MAXLEN = 5);
}