× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



so if anyone would like a look at coreiRST I just completed a video on it.

https://jeffersonvaughn.com/Corei-RST-REST/Webservice-Framework-Product/

or if you prefer a detour...

https://youtu.be/ptVh2ag0mAI

I also actually spent a lot of time today "re-facing" something things.
product avail for demo on my website.

Hope you enjoy.

Jay

On Mon, May 4, 2020 at 12:09 PM Nathan Andelin <nandelin@xxxxxxxxx> wrote:

I've been reviewing both RPGAPI from Daniel Long and COREIRST from Jay
Vaughn this past week. I'd like to comment on and question both. Please see
inline below.

1) this project runs inside a VPN as long as the future ones, so no need
for https so far


We have customers who began thinking they would access their web interfaces
via VPN then later changed their minds in order to save the administrative
hassles of managing VPN clients, user authentication and user
authorization. They ended up implementing HTTPS even though they were not
planning on doing that initially.


2) a single running program like this may be scheduled to start/stop at
specific times


In regard to "stopping" RPGAPI applications, have you found a way to do
that? Except for locating the Job and killing it with the ENDJOB command?


3) such a program may be easily debugged even by those who don't write
full
free RPG programs yet


Good point. In contrast to CGI interfaces, there is only one Job. So there
is no problem locating it and debugging it. On the other hand, what do you
do when many concurrent users are accessing the service concurrently? A CGI
interface scales by starting multiple instances and dividing workloads
between them. Will a single-threaded Job support all concurrent users?


4) the analysis of this project is a work in progress with the client,
meaning routes and routes' parameters are still changing (with IWS this
means the whole configuration must be set from scratch every time such a
change takes place)


Yes, that is a problem with IWS. But Jay was referring to his CGI
interface, which doesn't need to be stopped or restarted when routes are
added or removed. Actually, the RPGAPI interface would need to be stopped
and restarted, which seems like something of a disadvantage in comparison.


5) RPGAPI routes are much more similar to those in use among web
developers


In COREIRST the route are defined in a DB table, whereas with RPGAPI the
routes are hard-coded in the application. Is that really an advantage?


6) as arrays of arrays are implemented in many responses, writing JSON
responses is needed in any case


In regard to the format of generated responses, I don't see any difference
between the two. They are equally capable. But both are limited to about
32K.


In this first development stage, I follow both the Vue front-end and the
RPG back-end, and I am trying to code RPG service programs for them to
work
when called both via IWS and via RPGAPI server to keep future paths open:
when the whole procedure will reach a good level of consistency, I will
consider how to enhance some developing aspects. The decisions I make are
not perfect, I know it, but I need to balance both the complexity that
comes from the client's requirements, which imply more innovative
solutions, and the current state of the art of ICT people and environment
in general.


I have a hard time imagining anyone using IWS for REST web services if
they're comparing with RPGAPI. Just seems like a lot less configuration and
administration with RPGAPI. Plus better performance.
--
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.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.