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

Nathan,

Not interested in attracting developers....
Maybe an explanation as to what inspired me to do this...

Based on my past experience in the last 20 years at well over 10 different
shops (onsite)...

Many rpg shops i have been in have been structured in a way where the sys
admin and architects may put frameworks
in to place that the RPG developers work on. Those frameworks keep the
developers in a functional area that allows
them to efficiently do their relational database development with minimal
framework issues and distractions.
However, this whole separation of duties thing can be a bit of a
frustration for us developers that are anxious
to get into cross platform development, and where our organization has not
provided any sort of efficient way to
allow us to write our IBMi programs to move data to others.

This coreiRST product is designed with that in mind.

Having the right framework for this is critical... again so that our
developers can focus on translating business needs
to functional software, instead of getting lost in the weeds of "how will
this data get off our platform"?

So I would expect this coreiRST product be at the hands of an IBMi shops
lead architect or administrator. With this
very simple yet powerful framework, it can be deployed to allow your
development team to create API's with no learning curve
at all. (hence no rpg code shown in video - you already know it... though
we could all learn more sql/json).

I'd highly recommend producing these backend API's using json/sql. It is
incredibly clean and
efficient. Also I should add that this framework is NOT dependent on
that. If you can create a *PGM on the system, then
you can use this framework.

It is highly doubtful that if you worked at any shop I have been at
(thought times are a changing)... that you'd be able to develop a
backend RPG pgm that manipulates sockets so you can send data off
platform. Ain't happenin.



Jay



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

Jay,

It's nice to see you making improvements. Your video is missing something -
the RPG code required for receiving HTTP input and generating HTTP output.
You've done a nice job of automating HTTP server configuration, using a DB
table to link URLs to RPG programs, and viewing log activity.

But if you're interested in attracting developers, I think you need to show
the code for a web service.

With regard,

Nathan.


On Mon, May 4, 2020 at 3:15 PM Jay Vaughn <jeffersonvaughn@xxxxxxxxx>
wrote:

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

--
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

--
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