Re: Web service HTTP Basic Authentication - where to start from?

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.