|
Jay,interfaces
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/ [1] or if you prefer a detour... https://youtu.be/ptVh2ag0mAI [2] 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
via VPN then later changed their minds in order to save theadministrative
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.there
2) a single running program like this may be scheduled to start/stop at specific timesIn 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 writefull
free RPG programs yetGood point. In contrast to CGI interfaces, there is only one Job. So
is no problem locating it and debugging it. On the other hand, what doyou
do when many concurrent users are accessing the service concurrently? ACGI
interface scales by starting multiple instances and dividing workloads between them. Will a single-threaded Job support all concurrent users?a
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
comparison.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
difference5) RPGAPI routes are much more similar to those in use among webdevelopers 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 caseIn regard to the format of generated responses, I don't see any
between the two. They are equally capable. But both are limited to about 32K.the
In this first development stage, I follow both the Vue front-end and
open:RPG back-end, and I am trying to code RPG service programs for them towork
when called both via IWS and via RPGAPI server to keep future paths
arewhen the whole procedure will reach a good level of consistency, I will consider how to enhance some developing aspects. The decisions I make
environmentnot 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
andin 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
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 [3] or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx Before posting, please take a moment to review the archives at https://archive.midrange.com/rpg400-l [4]. 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 [5]-- This is the RPG programming on IBM i (RPG400-L) mailing list To post
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
