Good morning!
To start with, yes, the company I work for has an IBM i API solution, Profound API, and yes, I was the product owner during its early years. There are certainly others out there as well.
Now that that is out of the way. I can share what I have seen with IBM i shops moving into APIs, or webservices if you prefer.
Simply exposing your RPG programs through the methods mentioned certainly works and can be very simple. And that works great when you have 5 APIs, even 20, and they are only used internally.
But as your API usage grows, things like management, monitoring, documentation, authentication, authorization, etc. become critical. That's where a 3rd party API solution becomes a necessity.
If your APIs are consumed externally, how will you secure them? Basic Auth won't cut it. API keys can be exposed. Do you have the skills to implement OAuth 2.0 for your APIs?
Here is a whitepaper I wrote on API security that might be helpful.
https://info.profoundlogic.com/the-importance-of-api-security-to-protect-sensitive-business-data
It's not a sales pitch. In fact, it doesn't even mention our API solution except in the trademark boilerplate.
Brian May
Profound Logic Software
Global Customer Lifecycle Principal
http://www.profoundlogic.com<
http://www.profoundlogic.com/>
<
http://www.profoundlogic.com/>
937-439-7925 Phone
877-224-7768 Toll Free
[Profound Logic Logo]
________________________________
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> on behalf of Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx>
Sent: Friday, April 11, 2025 8:09 AM
To: rpg400-l@xxxxxxxxxxxxxxxxxx <rpg400-l@xxxxxxxxxxxxxxxxxx>
Cc: rpg400-l@xxxxxxxxxxxxxxxxxx <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Different approaches to expose RPG program outside of ibmi
Caution: This email originated from an external source. Please do not click links or open attachments unless you recognize the sender and know the content is safe.
Or potentially higher costs for software over and above IBM i.
Not to mention putting another vendor in the mix for the finger pointing exercise.
IBM i with stored procedures exposed to the view using HTML.
Too easy.
If I can do it anyone can.
Jim Oberholtzer
Agile Technology Architects
On Apr 11, 2025, at 7:41 AM, Justin Taylor <jtaylor.0ab@xxxxxxxxx> wrote:
Agreed. Even if .NET is currently your intended audience, the first option
provides better flexibility for the future without requiring much extra
effort.
On Fri, Apr 11, 2025 at 3:34 AM cesco via RPG400-L <
rpg400-l@xxxxxxxxxxxxxxxxxx> wrote:
Wide question with obviously a lot of options and lot of context and
solution area, but being precisely so wide, let's stick to the two options
given, assuming you are talking about JSON over HTTP RPC style API.....
I'll pick the first, less moving parts, efficient, easier to debug, and
pretty performant if Apache straight to RPG. And - if one so desire - there
are native third party products for IBMi that offer the whole stack and
related orthogonal services (security, accounting, monitoring...).
The second doesn't add any visible value to me, the cost of such
dependency is much higher than the value given.
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
midrange.com
