Introduction

Nowadays, there is a lot of applications that are using Open Authorization framework (OAuth) to access resources from all kinds of services in a secure, reliable and efficient manner. InterSystems IRIS is already compatible with OAuth 2.0 framework, in fact, there is a great article in the community regarding OAuth 2.0 and InterSystems IRIS in the following link here.

Those of you who are following the FullStack competition here in the Developer Community will know that I submitted an entry named qewd-conduit.  I wanted to summarise why I think it's something worth you taking a bit of time to check out.

qewd-conduit uses the Node.js-based QEWD framework alongside IRIS to implement the back-end REST APIs for something known as the RealWorld Conduit application:

https://github.com/gothinkster/realworld

Hi Community,
 
OpenAPI-Client Gen has just released, this is an application to create an IRIS Interoperability Production client from Swagger 2.0 specification.
 
Instead of the existing tool ^%REST that creates a server-side REST application, OpenAPI-Client Gen creates a complete REST Interoperability Production client template.

Install by ZPM:

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.

As a result of Evgeny's recent questions regarding the use of QEWD.js with IRIS in another post, I thought it would be a good idea to create a separate post focusing specifically on how to use QEWD.js to create REST APIs for IRIS.

QEWD.js is,  of course, a Node.js framework, and all the REST API code can be written entirely in JavaScript. 

I already talked about GraphQL and the ways of using it in this article. Now I am going to tell you about the tasks I was facing and the results that I managed to achieve in the process of implementing GraphQL for InterSystems platforms.

What this article is about

• Generation of an AST for a GraphQL request and its validation
• Generation of documentation
• Generation of a response in the JSON format

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.

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.

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 -

In this article I'll describe how to set up web services and/or REST services using EWD 3.

Since EWD 3 is designed to be modular, you can construct the environment that exactly meets your needs, but for much of the time you'll probably find that the pre-built EWD 3 ewd-xpress super-module does most of what you need because it hooks together all the core EWD 3 and other building-blocks you'll need:

IRIS provides us with anti login CSRF attack mitigation, however this is not the same as a CSRF attack, as login attacks only occur on the login form. There are currently no built-in tools to mitigate CSRF attacks on api calls and other forms, so this is a step in mitigating these attacks.

See the following link from OWASP for the definition of a CSRF attack:

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

Introduction

We are in the age of the multiplatform economy and APIs are the "glue" in this digital scenario. Since they are so important, they are seen by developers as a service or product to be consumed. Therefore, usage experience is a crucial factor for its success.

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.

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.