The API economy has come a long way since the days when I worked at a very well-known automotive website back in 2007. Back then, APIs were the thing that application programmers used at a very low level. Programming using web-based APIs was a rarity. In those days, we downloaded libraries into our local codebase and programmed against those binaries. I was programming in Java at the time, so the general practice was to use an application management framework such as Maven to get .jar files from the internet and incorporate those .jars into my code.
Yes, there were technologies such as RPC that allowed us to access functions running on other machines directly and there were shops that used the technique extensively, but in my little corner of the world we accessed services directly through in-memory binaries. Also, we—the automotive website—published our data as HTML in web pages.
Then something happened around 2010. It turns out that other developers outside the company wanted to use our automotive data. In fact, a lot of developers wanted that data. My employer saw the writing on the wall. Within a year, we were publishing an API that provided all the information we had on just about every car sold in the United States. We were in the API Economy big time!
It was a transformational undertaking. It was also incredibly taxing. The company had to alter a lot of its development processes to meet the demands API publishing. Not only did we need to support publishing the data under XML and JSON, we also had to put in a security layer to make sure only those developers who were entitled to use the API had access. And, we had to provide comprehensive documentation that provided the support necessary so that a developer could use the API to full efficiency. The work beneath the surface of the API to keep data flowing and current was even more daunting. And, this was only for V1. We had yet to develop any sort of road map that described future versions.
Was it hard work? Yes. Was it worth it? Yes. We were at the forefront of the API Economy. Moving our data out of HTML and into machine-readable formats such as XML and JSON provided a lot of commercial value, to the company and to other developers. It was a game-changer then. It’s game-changing now.
The good news is that technologies have emerged that make API publishing easy compared to those early days. Today, most of the major players in the technology landscape realize that to stay commercially viable, they need to represent their services as robust APIs in a way that is easy to publish and easy to consume at web-scale. This is particularly true in the realm of mainframe computing.
IBM Z Systems: A Significant Player in the API Economy
There’s a lot of mainframe technology in force in the world today. A very large number of banks, financial services, governments and large-scale transportation entities have major mainframe installations. Many of these installations are IBM Z Systems. IBM is major force in this landscape—always was, always will be. With a workforce of more than 300,000 people, how can it be otherwise?
One of the things that IBM has been very good at doing is devising technologies that allow services that reside in their Z System installations to be exposed as APIs. The way they do this is using a technology called z/OS Connect EE. z/OS Connect allows developers to expose Z System applications as APIs accessed via HTTP (See Figure 1.)
Figure 1: z/OS Connect EE serves as the intermediary between an HTTP based API and a IBM Z mainframe
Developers create an API using the z/OS Connect EE API Editor. The API Editor is an Eclipse-based IDE that allows developers to define the endpoint URLs for an API. (See Figure 2, below.)
Figure 2: The z/Connect EE API Editor allows developer to define the HTTP methods and associated endpoints to that make up an API
Then, once the endpoints are defined and HTTP methods (e.g., GET, PUT, POST and DELETE) are bound to services that reside in the Z System installation. (See Figure 3.). Each service maps to an application, such as a transaction in CICS, IMS, DB2, etc.
Figure 3: z/OS Connect EE provides a way to directly bind an HTTP request to mainframe resources
Not only does the z/Connect allow developers to represent services in a Z System as fully functional APIs, but it also has a feature that exports API definition as fully compliant Open API specifications.
This is a big deal.
Open API is one of the three most prominent API specification formats in use today. (The other two are RAML and API Blueprint.) A developer can use the Swagger specification that z/OS Connect generates to create interactive documentation for use by third-party developers. (See, Figure 4.)
Figure 4: z/OS Connect EE has the ability to generate an API specification in Open API format that can be used to create interactive, online documentation automatically
Again, this is a very big deal. One of the key factors for publishing a successful API is to provide comprehensive documentation. An API that is poorly documented rarely becomes a hit in the API Economy. The more comprehensive an API’s documentation is, the more widely used it will be.
| z/OS Connector EE + Eclipse = A marriage made in heaven I am a big supporter of using tools to reduce the labor of working with complex technologies, particularly with something as broad and multi-faceted as mainframe computing. The z/OS Connect EE API Editor fits the bill. It’s embedded within the Eclipse IDE. If you know how to use Eclipse to make a Java program, you’ll find using z/OS Connect EE API Editor to create Z System API to be an inviting experience. Yes, you might have to spend some time get up to speed on mainframe technologies such as CICS and COBOL. But, the good news is you won’t have to learn a new programming environment to do it. Just think of the API Editor as Eclipse wrapped around z/OS Connect EE and the IBM Z System computing environment. This 10 minute video does a really good job demonstrating how to use the Eclipse based z/OS Connect EE API Editor to create a full blown REST API using services provided by a IBM Z System mainframe. It’s pretty amazing. |
Once an API is published from a z/OS system, it can be used internally or exposed for public consumption. Representing Z System services as an API – is a significant step toward making mainframe technology a first-class contributor to the API Economy. In the API Economy, consumers care little for the underlying technology. What matters is the service. It’s striking in a way: What may look like a cloud-based API on the outside is really an IBM Z System underneath the covers.
The API Economy Moving Forward
The API Economy has come a long way since those first days almost 10 years ago when we wrote our first GET /make/mode/year request at the automotive website. The days of hard-coding routes and manually creating documentation have come to an end. Good riddance. To be honest, that type of development was not only a waste of labor, it also was questionable programming.
Today, modern tools such as z/OS Connect EE API Editor allow developers to focus on the challenges of designing APIs that make a difference. The focus on design is critical, particularly as we move into the era of the internet of things (IoT). In the not too distant future, most API activity will be conducted between machines—small devices, many pushing the boundaries of miniaturization, talking among themselves and to other larger systems. The volume of data these devices will create will be well beyond today’s norms. Interestingly enough, mainframe technology is geared to handle this extreme volume of data.
Mainframe technology will play a major role in the IoT ecosystem and the API Economy. If I were a gambling man and I wanted to position myself to be in the right place at the right time as the API Economy evolves, I would place a significant bet on getting involved in Z System development now. Technologies such as z/OS Connect EE and its API Editor open the doors to many lucrative opportunities. It’s up to us to make the decision to walk through them.
