Application Programming Interface (API) is a set of subroutine definitions, protocols, and tools for building application software. In general terms, it is a set of clearly defined methods of communication between various software components.
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
InterSystems API Management (IAM) - a new feature of the InterSystems IRIS Data Platform, enables 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. And here's an article explaining how to start working with IAM.
In this article, we would use InterSystems API Management to Load Balance an API.
In our case, we have 2 InterSystems IRIS instances with /api/atelier REST API that we want to publish for our clients.
There are many different reasons why we might want to do that, such as:
Load balancing to spread the workload across servers
Blue-green deployment: we have two servers, one "prod", other "dev" and we might want to switch between them
Canary deployment: we might publish the new version only on one server and move 1% of clients there
Hi Community!
Today I'd like to share with you a link to some exercises from a workshop about developing REST APIs and how to manage them using InterSystems API Manager.
A concurrent session in IRIS: SQL, Objects, REST, and GraphQL
Kazimir Malevich, "Athletes" (1932)
"But of course you don't understand! How can a person who has always traveled in a horse-drawn carriage understand the feelings and impressions of the express traveler or the pilot in the air?"
Kazimir Malevich (1916)
Introduction
We’ve already addressed the topic of why object/type representation is superior to SQL for implementing subject area models. And those conclusions and facts are as true now as they have ever been. So why should we take a step back and discuss technologies that drag abstractions back to the global level, where they had been in the pre-object and pre-type era? Why should we encourage the use of spaghetti code, which results in bugs that are hard to track down, and which relies only on virtuoso developer skills?
There are several arguments in favor of transmitting data via SQL/REST/GraphQL-based APIs as opposed to representing them as types/objects:
To anticipate the obvious reply that InterSystems IRIS supports WebSockets natively as a client: This is correct and here is my aged related article with the link to the example in OEX
In the context of IKO (Iris Kubernetes Operator) the question of Service not redirecting dynamically to the correct Pod is still pending. In production this can be dangerous since an overload (or any other simpler problem) can cause you to change the main Pod and leave the application inoperable until we intervene.
Intersystems support warned that this is still an issue of IKO, but there are some possibilities that I am studying.
To explore an idea I had, I would like the help of this Forum to answer the following question:
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.
Following Issue: When I update a SQL table like (update OnlineV3Admin.ParameterApp set popuptext = '' where ID = '1') and then read it for my Json WebService there is a /"x00" in my Json.
What is the best option to disable that? I need here a empty String and not /x00.
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.
I have a Problem with the Session Handling in .csp.
I wrote all my Web Services in .csp-Pages and do the work for example in the OnPreHttp Method for to get some data.
After that the Web Service response is in JSON.
I call These Web Services via fetch in my react Single Page application, also Many request parallel. The react App is Rolled out as index.html. Everything Works Fine with the session Handling via Cookie.
Our organization is going to implement an Identity provisioning service using SCIM standard (1.1), I am just wondering if Intersystems System IRIS for health has SCIM adapter or any class that already built for SCIM standard...
I've run into an issue where job IDs are being retained through multiple calls. My team is doing a rewrite of our system that allows VB6 apps and web apps to directly interact with our Cache databases.
The new process has those applications calling into a WebAPI which then calls into the routines.
This is a coding example working on IRIS 2020.2
It is also NOT serviced by InterSystems Support !
The demo is based on the raw class descriptions. The data classes used are Address, Person, Employee, Company For a more attractive demo, a JSONtoString method by ID was added.
It seems to me that for some reason this didn't make its way to the official documentation and seems to be rather unknown though implemented already in IRIS 2020.1
Thanks to @Dan Pasco I got a hint on the classes involved. I used the recommended sequence of how to use it. it is all directly taken from Class Reference and I just collected it to create a first overview.
a HealthConnect customer of ours came across with a question to use an external service via REST and OpenID within one of his HealthConnect (2020.1) productions. The overal idea is to send data to the external system after receiving a baerer token to use for the communication between HealthConnect and this system.
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.
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.
We have an immediate requirement for an experienced Intersystems Ensemble/Health Connect consultant to join our team with a good grounding in OO Programming, Healthcare Integration and at least 2 years experience with InterSystems Ensemble/Healthshare Health Connect
By update
9m read
Open Exchange app
