I'm just trying to eliminate failure points and keep things in an
environment where I have control. Why have the browser use HTTP connect to
a windows server (that I have no control over...different teams) for the C#
program to ODBC connect to the IBM i when I can just HTTP directly to the
IBM i?

I was also looking to use RPGLE because I know it. I have already bitten
off more than I can chew with this thing and taking on the learning of yet
another language might just push the whole project into the bit bucket.


-----Original Message-----
From: WEB400 <web400-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Richard Schoen
Sent: Saturday, October 8, 2022 2:33 PM
To: web400@xxxxxxxxxxxxxxxxxx
Subject: Re: [WEB400] Creating a REST API with RPGLE

Out of curiosity is there a reason you can't still use C# ?

Web apps and web apis done in C# and hosted on Windows or Linux are quite
usable as well and can interact with your RPG via ODBC database calls and
the IBMi Access ODBC driver.

You also have things like Java, Python, Node and PHP available.

Another interesting option if you want to create an RPG web service is
ILEAstic.

You have options.

Regards,
Richard Schoen
Web: http://www.richardschoen.net
Email: richard@xxxxxxxxxxxxxxxxx

----------------------------------------------------------------------

message: 1
date: Fri, 7 Oct 2022 20:54:11 -0400
from: smith5646midrange@xxxxxxxxx
subject: [WEB400] Creating a REST API with RPGLE

First, let me say I am trying to do something here that I have zilch
experience with from the IBM i perspective. I have done this type of stuff
using C#.Net on Windows but nothing on the IBM i. Yesterday was my first
voyage into IBM Web Administration for i.

That said, I am trying to create a REST API written in RPGLE that will
return JSON data. I have looked at a lot of examples but just can't find
what I am after.

This needs to be modeled after some existing C#.Net REST APIs so the
following requirements are not negotiable.

The request needs to be a POST type.
The body of the POST request needs to have two "fields".
1) Input - An SQL statement that will be used to retrieve the data.
2) Output - The results of the SQL. These results can be anything so the
fields can't be predefined in the RPGLE program's parameters like they are
in all of the examples that I find. There can also be multiple records so
it would end up having an array in the results. I think I need a single
"results" field that is pretty big and I will need to manually build the
JSON for it.

I tried creating a new HTTP server and deploying a service to it. I have
been successful using Scott's customer lookup as a model and I have been
able to do a few different things to experiment. However, I can't figure
out how to handle the POST body for input or the array results in the
output.

One attempt was to create the following:
dcl-pi *n;
sql char(5000);
resultSet char(50000);
end-pi;
The problem was that I got back a value in the resultSet that was really
junked up JSON because it escaped all of the " as \". I considered trying
to make the resultSet value return as plain text instead of JSON (I'm
assuming I can do that somehow) but I decided before I went too far down the
wrong rabbit hole, I would ask for help.

Can someone help point me in a good direction? I don't mind doing a lot of
web digging, I just don't really know what I need to search for to do the
digging.

Thanks.


--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list To post a message email: WEB400@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx Before posting, please take a
moment to review the archives at https://archive.midrange.com/web400.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.