A question came up in the InterSystems developer community concerning the possibility of

Beginner’s guide to RESTful Application Program Interface (API) design and documentation. Through the example you will learn some common pattern for RESTful API.

Before you read

You need to know

This article is a continuation of this post.

In the previous article, we discussed the development of business processes, which are part of the components required for system integration and serve as a production coordinator.

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)

This is a beginner’s guide to the design of a “MicroService” implemented in Ensemble. “MicroService” is a popular phrase these days which has a broad interpretation. My interpretation is: “MicroService” is a “NoSQL Service”. A what? The answer is in the article.

We learnt what the difference is between SQL and NoSQL databases. For me the difference is nearly the same between a SOA Web Service and a “MicroService”. I am going to explain it through an example.

In this 3-part series of articles, is shown how you can use IAM to simply add security, according to OAuth 2.0 standards, to a previously unauthenticated service deployed in IRIS.

In the first part, was provided some OAuth 2.0 background together with some IRIS and IAM initial definitions and configurations in order to facilitate the understanding of the whole process of securing your services.

Presenter: Danny Wijnschenk
Task: Build a development stack that enables state-of-the-art rapid development with a stable but adaptive back end.
Approach: Use InterSystems’ new document data model to achieve modern full-stack development

The MEAN stack is a very popular stack for building applications quickly that can change at a rapid pace. We will explore the benefits of such a stack and how you can tackle the requirements for modern and fast paced front-end development with support of a stable, but yet adaptive back-end using our new document data model.

Content related to this session, including slides, video and additional learning content can be found here.

Hello again and welcome to the next tutorial on this series: Part 4 - Sharing data across router methods. Here we are going to learn how to share a object containing data that is available for read across every router methods.

You're required to complete at least the Part 1 before entering this one. Still, this is supposed to be a really short tutorial, since there isn't much to be said about data sharing.

Presenter: André Cerri
Task: Use third-party visualization tools to present your DeepSee data
Approach: Use DeepSee REST services to access DeepSee data from third-party tools

Come see examples of how you can use popular 3rd party data visualization tools to access your DeepSee data.

Content related to this session, including slides, video and additional learning content can be found here.

Say I've been developing a web application that uses IRIS as the back end. I've been working on it with unauthenticated access. It's getting to the point where I would like to deploy it to users, but first I need to add authentication. Rather than using the default IRIS password authentication, I'd like users to sign in with my organization's Single Sign On, or some other popular identity provider like Google or GitHub. I've read that OpenID Connect is a common authentication standard, and it's supported by IRIS. What is the simplest way to get up and running?

The first installment of this article series discussed how to read a big chunk of data from the raw body of an HTTP POST method and save it to a database as a stream property of a class. The second installment discussed how to send files and their names wrapped in a JSON format.

Now let’s look closer at the idea of sending large files in parts to the server. There are several approaches we can use to do this. This article discusses using the Transfer-Encoding header to indicate chunked transfer. The HTTP/1.1 specification introduced the Transfer-Encoding header, and the RFC 7230 section 4.1 described it, but it’s absent from the HTTP/2 specification.

This week I was able to demo a proof of concept for our FMS interface on traffic cop architecture to my team. We are working on modernizing an Interoperability production running on mirrored Health Connect instances. We deploy IRIS workloads on Red Hat OpenShift Container Platform using InterSystems Kubernetes Operator (IKO). We can define any number of replicas for the compute stateful set where each compute pod runs our Interoperability production. We introduced Horizontal Pod Autoscaler (HPA) to scale up the number of compute pods based on memory or CPU utilization.

As Rob explained in an earlier post, Caché's Node.js interface allows you to create Web Services and REST Services using the very modular EWD 3 framework.

I deployed online demo here: