The Growing Relevance of REST APIs
Note: This podcast transcript is lightly edited for clarity.
Paul Tuohy: Hi everybody and welcome to another iTalk Business with Tuohy. I am yet again delighted to have with me my friend for many, many years now I think and now working with Midrange Dynamics as their development and solutions architect Scott Klement. Hi Scott.
Scott Klement: Hey, Paul, how are you today?
Paul: I’m pretty good, and it’s kind of cool, Scott. I know people can’t see this, but I’m looking at you on camera here and I’m admiring that fine shirt you’re wearing.
Scott: Well, thank you.
Paul: A good old RPG and Db2 Summit shirt.
Scott: I don’t have to keep it from wearing out anymore because there’s no more conferences to go to, so I can wear it all the time now.
Paul: Yup [laughs]. Okay so Scott, today we are going to be talking mainly about REST APIs. So I think maybe a good place to start is maybe if you can fill us in on what you see as being sort of the relevance of REST APIs, of where they fit into the scenario.
Scott: The relevance of REST APIs—as IT people we are kind of used to thinking of REST APIs as a way to integrate things like web pages and mobile apps, but I think from the perspective of some of the more senior people, the managers and executives and just business people within the company, they don’t necessarily realize what REST APIs are and why their company should be investing in them. So, REST APIs are all about communication, and communication specifically between programs, usually across different computers, and that’s very important as more and more applications get moved into the cloud. You still have other applications that are on premises, you need them to be able to communicate with each other, but not just that. Think about where we’re going. So if you work in the warehousing industry, there’s no question that you’re considering doing more automation with robots, or if you’re in manufacturing of course, you’re probably already using robots. Think about Amazon’s warehouse. They’ve got robots going over these huge warehouses and picking the product and bringing it up to workers to pack up orders. How do these robots know where that inventory is located or what inventory to go get? They use a REST API to communicate with a back end system of record. So that’s where IBM i comes in. IBM i is probably the best, most stable system in the world for running your business, keeping it running efficiently, having all those back end records [is] the heartbeat of your company, what’s going on with everything in the company. So things like robots can communicate with REST APIs—things like mobile apps and web pages when they need to look up what’s happening with customers, or for a customer to look up the status of their order, just so many different ways, and also for sort of traditional EDI type tasks like communicating orders to vendors or customers communicating orders to you and integrating computer to computer type mechanisms. It’s hard to do very much today because so many systems are involved and they all communicate with each other. REST APIs are the safe and secure way for us to do that. Traditional ways that people have used, like FTP of file back and forth and then launch some process, is not very secure. Something like opening up your database, providing like a direct JDBC or ODBC communication between systems—it’s fine in a protected local area network, but once you go beyond that the problem isn’t that they’re insecure, it’s that if somebody does break that security, they have access to everything. In the case of REST APIs, you have access to only what that API does. Where with database driver, if you somehow break that security, the whole system is open to you. So REST APIs are where we are today in terms of communication, and it’s exploding with all of the things going on in the world.
Paul: Yeah. If I can throw in on that, Scott, I mean I know you didn’t mention it in there but of course as people venture into AI and everything as well—like most of the AI stuff is being done through REST APIs communicating with AIs.
Scott: Right, unless you’re running the AI yourself on your own computer which almost nobody is doing except for the AI companies themselves.
Paul: Yeah, yeah.
Scott: So if you want to communicate with GPT-4, you’re probably going to use a REST API to do it, or WatsonX or something like that.
Paul: Yeah, yup, yup. So Scott, tell me, with all this REST stuff sort of generally, so what kind of things are Midrange Dynamics doing in this area?
Scott: What do we do with REST APIs—our flagship product is MDChange, and the core part of MDChange is MDCMS, a change management software for IBM i. One of the things that we have found though is that more and more our customers are part of a large enterprise, and those large enterprises can’t use MDCMS across the board because they have many other platforms besides IBM i. So they want to use something like Git on the back end, or maybe something like Azure DevOps, something like that to put it all together. So what we have done is we have integrated our product with all of these other solutions—with ServiceNow, with Jira, with SonarQube—to do analysis on your code, to do Azure and other Git-related servers—GitLab, GitHub, Bitbucket—so that you can have MDCMS do the local IBM i work and communicate it all out. This is one of the things that has given us a tremendous competitive advantage over our competitors, because no one else is doing that. The way that we are able to do that is by having MDCMS communicate with REST APIs, and internally we also use REST APIs for our graphical front ends. So if you’re using something like VSCode as a developer—which I think we’re all going towards if we’re not there yet, I think that’s where we’re going—our change management software needs to communicate back to the IBM i to work with the core change management, and the way it does that is through REST APIs. Our actual REST API product, MDRest4i of course, provides the same functionality towards customers, but we’re using it ourselves to enhance the rest of our products—the REST of our products.
Paul: Oh, oh, stop [laughs]. So basically you are actually drinking your own Kool-Aid here, Scott.
Scott: Yeah, I know exactly how I like to make my Kool-Aid. I love to drink it [laughs] and it is so sweet. All right, this is getting off track.
Paul: Okay well I think it leads us in a little bit, Scott, because I think if I remember correctly, the last time we spoke, you were just sort of coming or maybe just around release 1 really of that revamp that you were doing on the Rest4i. So you want to bring us to speed on all of that and what’s been going on, and maybe some stuff that might be in the works?
Scott: We decided to hold back on that and put a lot more into it. Originally when I was talking to you last time, I was talking about just revamping just the framework that the customer programs use, and we’ve decided to revamp our generators. So if you’re not familiar with MDRest4i, the concept is you can basically tell MDRest4i what your payload should look like, and there are several different ways to do that. The sort of most standard way is to provide what’s called a Swagger or Open API document. This is a JSON document similar to the WSDL documents we had in the days of SOAP that you can just upload to our web interface and it will generate programs to call the APIs, but it’s not just that. For example, if you have a database table on your IBM i that has the layout of the fields that you want to send in your REST API, you can point it at that and it will generate the API, or you can copy and paste the parameter section of an RPG program. We’re also adding a support for COBOL as well. You can also do like a JSON payload, just the payload portion without it being a Swagger document. So that idea behind this generator is to make it dead simple for anyone who wants to use this fantastic framework that I was talking about last time, that’s 16 times the speed of the previous ones. But now you can just say this is what I want to create, and it will generate the RPG code to do this automatically, or COBOL code as well to do this automatically. We’ve been working really hard and fine tuning that to make that RPG code as elegant as possible and the COBOL code as elegant as possible so that all you have to do is write your business logic, you know the parts that are unique to your company, and get that in there and that will be it—you’ll be able to both provide and consume any API. It’s very, very versatile.
Paul: So do you see it as sort of a game changer, Scott, for businesses—I mean in terms of bringing them up to speed, or put it another way, keeping them in the race?
Scott: I think REST APIs themselves have been a game changer and will continue to be as more and more companies adopt them, because that integration that I was talking about earlier is so critical. As we move forward in the future, more and more factory automation—we’re going to have driverless cars. We’re going to have robots doing things for us. We’re going to have more stuff stored in the cloud that we’re going to need to communicate with. We’re going to have more stuff on mobile apps. We’re going to have more stuff available to customers through the web. All of these different things make REST APIs themselves a game changer, and what MDRest4i provides is a way to make it easy. If you’re an RPG or COBOL developer, instead of spending a couple of hours, maybe for an expert like me, or days or weeks for someone who is more or less familiar, creating your API, now with MDRest4i it’s minutes to put that out there, and it contains things like documentation systems and stuff like that to create a real enterprise choice. The alternatives that are out there just don’t have the versatility. I don’t want to name names, but I know one particular very popular API solution that IBM provides with the system—it’s nice but it’s just not versatile enough. You can’t go out and say I’m going to call ChatGPT or I’m going to call WatsonX or I’m going to call Azure DevOps and just point that at it. It just isn’t versatile enough to understand it. So we provide a solution that can do any aspect of APIs, where our competitors just can’t do that and we do it in a way that’s easier than anything else.
Paul: Cool. And yes, because I have actually had a glance at it and yeah—Scott does not lie. So listen Scott, before we finish up on this, there’s one other thing I want to maybe ask you to chat to us about. It’s something that as I now veer off into my retirement, this sort of becomes an interesting topic because it’s the other end of the chain, which is sort of the new people and that coming on the platform. So do you want to talk a little bit about mentoring?
Scott: So this is what I look for. This is what like makes me want to come into work everyday, is mentoring young people. I just get so much satisfaction out of it. It’s almost like being a father, right? You know when you’re a parent, you have your kids and you watch them grow and you watch them develop and get better, and that’s kind of how I see mentoring—except you start much later in the process, obviously. I just enjoy it so much and when you go to the different conferences or online forums or what have you and you talk to companies, what is going on? What are your biggest challenges? What you hear over and over and over again is people are retiring. More and more people are reaching retirement age and we can’t find anyone to fill their shoes, you just keep hearing this over and over again. So there are plenty of people going into computer programming and IT—unfortunately, not nearly enough are going into IBM i. So my thinking is what helps is to bring someone from another walk of life I want to say, but it’s not really a different walk of life, just a different programming language on a different platform. They’ve already proven they have the mind for programming, and that’s really the key element, but then just sit and work with them and watch them learn the platform. Watch their delight as they start to understand why I love this platform, why I love these languages like RPG, and I get so much satisfaction out of that. I just love doing that, working with young people. So through COMMON’s New to i or Into i program, I’m working with several mentees. Outside of that, I had my son I was mentoring over the summertime, and I intend to continue that. I want to bring in another mentee to work with me at Midrange, and I just feel like it’s so many people right now that I’m trying to mentor, like four people, but then on top of that what I really have been doing as well in my free time is I’ve been doing robotics. I think robotics is very important to our future. I don’t think anyone will argue that point, and our high school robotics team—my son was a member of it last year. He has graduated now but I stayed on, and so I’ve got all these kids that I just adore working with them, and I’m teaching them to program. And in this case program a robot rather than IBM i, but it’s hopefully going to eventually turn into them being interested in what I do and moving into that down the line. I just get a lot of satisfaction out of working with young people and bringing them into the world of computers, and I think especially IBM i when they see what’s so great about this platform.
Paul: Yeah, so as you know, we’ve had conversations along these lines before, Scott. I mean I know exactly what you’re talking about, obviously from my training side but it’s—yeah, yeah.
Scott: There’s that happy dance you do when you get your program working and it does exactly what you wanted it to do and no one else has done that before. You kind of do that happy dance. I just love that.
Paul: Yeah, yup, yup. It is, so please keep that up. So listen Scott, we’ve reached the end. Do you have any final message you want to pass onto people, apart from telling them to go and check the website and check out Rest4i?
Scott: Well that’s obviously a big thing for me right now, since that’s the business that I’m in. If you can check it out, if you’re in North America, it’s www.md-na.com, or the rest of the world it’s midrangedynamics.com. But aside from that, I want to wish you well, Paul. I know that you are embarking on your retirement and you’re probably have a much better life than I do from here forward, but I want to wish you good luck [laughs].
Paul: Thank you, Scott. Thank you, I appreciate that. Well I think that’s a good note to leave it on everyone, and so thanks for turning in and watch out for what Scott’s going to be doing in the future, because as always, it’s going to be good. Okay, bye all.
Scott: Bye.