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)

Hi! recently I have to apply api-key validation to a web app with a lot of endpoints and I'm going to tell you how I did it in a centralized way.

I'm going to explain you how we can apply in a generic way (or not) api-key validation to all the endpoints of our web app.

Hi Developers!

Suppose you have a persistent class with data and you want to have a simple Angular UI for it to view the data and make CRUD operations.

Recently @Alberto Fuentes described how to build Angular UI for your InterSystems IRIS application using RESTForms2.

In this article, I want to tell you how you can get a simple Angular UI to CRUD and view your InterSystems IRIS class data automatically in less than 5 minutes.

Let's go!

Applications that work with bill payments and receipts, as well as the delivery and inventory of items, generally require the use of barcodes or QR Codes. The latter is used in even broader scenarios since the QR Code can store more information than a simple bar code. Thus, it is important to have the ability to generate barcodes and QR Codes or read the data stored in them from an image or a PDF. This article will show you how to do this using Python and some of its free libraries.

Intersystems IRIS for Health has excellent support for the FHIR industry standard. The main features are:
1. FHIR Server
2. FHIR Database
3. REST and ObjectScript API for CRUD operations on FHIR resources (patient, questionnaire, vaccines, etc.)

This article demonstrates how to use each of these features, as well as presenting an angular frontend for creating and viewing Quiz-like FHIR resources.

In this article, I would show how you can upload and download files from InterSystems products via http.

The questions about working with files over http arise fairly often on community and I'm usually linking to my FileServer project which demonstrates file upload/download but I'd like to talk a bit more on how we can serve and receive files from InterSystems products.

I deployed online demo here:

This is a detailed guide to develop RESTful services using InterSystems Ensemble. The goal of this guide is to make you understanding the basic concept and building blocks of a RESTful service. The service is going to provide a very basic functionality (a “Hello world!”).

You will learn how to create required components as Ensemble classes, configure the run-time as an Ensemble Production and create a service configuration as a web application.

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.

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!

As I was thinking what I could develop for InterSystems Full Stack Contest, I saw this post:

While reviewing our documentation for our ^pButtons (in IRIS renamed as ^SystemPerformance) performance monitoring utility, a customer told me: "I understand all of this, but I wish it could be simpler… easier to define profiles, manage them etc.".

After this session I thought it would be a nice exercise to try and provide some easier human interface for this.

The first step in this was to wrap a class-based API to the existing pButtons routine.

I was also able to add some more "features" like showing what profiles are currently running, their time remaining to run, previously running processes and more.

The next step was to add on top of this API, a REST API class.

With this artifact (a pButtons REST API) in hand, one can go ahead and build a modern UI on top of that.

For example -

1. Fhir-client-python

This is a simple fhir client in python to practice with fhir resources and CRUD requests to a fhir server.

Note that for the most part auto-completion is activated, that's the main reason to use fhir.resources.

GitHub

1. Fhir-client-net

This is a simple fhir client in c# to practice with fhir resources and CRUD requests to a fhir server.

Note that for the most part auto-completion is activated.

GitHub