Hi.. I have an issue where we are using OAuth2.0 with the ZAUTHENTICATE routine. Once our token is validated we are using a users lan id (passed on the ID token) to find a software defined username in a Cache Global.

That is all working fine in ZAUTHENTICATE.. I am setting the software defined username in the Properties("Comment") array and wanting to reference it in the Rest Service Dispatch class.

After some trials, I am comfortably on my way developing spec first REST APIs using /api/mgmt/, OpenAPI 2.0, testing with Postman.

My question is related to scaling up.

Assume these things:

- Our software is CSP web app and it's web application is '/csp/application'

- I created a new REST enabled web app called '/csp/application/v1' and for my first API I created a spec that defines an endpoint /getTeapots so the endpoint is localhost/csp/application/v1/getTeapots

- Using the /api/mgmt/ endpoint, I loaded the spec into API.TeapotLibrary

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

Add a credential to login the FHIR REST interface - in this case only consider a basic authentication

Hi everybody,

I'm modifying a REST interface for a client but it seems impossible to me to modify HTTP Response Status and including custom HTTP Headers either.

My dispatch class (extending %CSP.REST) is contacted through a POST request and the latter is processed in a custom class (extending %CSP.REST as well) accessed as shown in the example below:

<Route Url="/test" Method="POST" Call="Custom.Test:Process" />

Within the processing class I tried executing the following statements with no success:

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 there,

I'm trying to develop a program calling Cache REST service twice with Cors. The first is fetching some information of a patient with GET request, the second is using obtained information to call another REST service(implemented in the same class though) with POST to perform other tasks.

Hello everyone!
I have manually created a REST-service that receives incoming HTTP-GET calls together with an URL-map. As shown below:

A beginners guide to develop Ensemble RESTful web services.

Background

Before you start reading this short introduction please go through the on-line documentation of Ensemble with special attention to chapter “Creating REST services and clients with Ensemble”.

The approach in the documentation is undisputable the fastest and easiest way to create RESTful services. As a beginner I went through the documentation and I had several questions. This short article is listing those questions plus my humble answers.

Hi team,

i send an http request to my rest class, i want to extract ID , full name , pass word from this request , can you show me how doing it.

thank's

This article is translation of one from Habrahabr InterSystems blog (Russian).
The original post can be found here: https://habrahabr.ru/company/intersystems/blog/251611/

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!

Hi Developers!

Here're the technology bonuses for the Full Stack Contest that will give you extra points in the voting:

• InterSystems IRIS REST API Usage
• InterSystems Native API Usage
• InterSystems JDBC Usage
• Unit Testing
• ZPM Package deployment
• Docker container usage

See the details below.

Hello Community,

When handling a %CSP.REST API response for a custom endpoint, how can I capture or access the response content before it is written to the output buffer and sent through the Web Gateway to the UI?