Re: receiving POST encoded in JSON

On Mon, Aug 3, 2015 at 1:06 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

@Bradley

Maybe I have another approach - programmers do not need to understand
why a service sub-procedure is build as it is build - middleware takes that
understanding out of the equation and the programmer can concentrate
on what the sub-procedure does.

That's why I included examples that use middleware. :) I didn't break
things down to the lowest level or intend on provided the code behind the
middle where. The exception in this specific case was for the QtmhRdStin
API and an example using it to read in more than the "max" RPG parameter
can handle (because of a size limitation of a string in RPG).

The example used this one API to read the entire content into a Stream
File. Even the stream file middleware used is easily replaced with
something of your choosing, or even the APIs themselves.

With the examples I gave, if someone understands at a higher level what is
going on, then the middleware should be easily substituted (ie, GETURI vs
Scott's HTTPAPI, eRPG SDK vs CGIDEV2, and the JSON parsers, etc).

Have you looked at CGIDEV2 sub-procedures and how they interact? I
will guarantee that we are less that 10 programmers of the 15.000+
that uses CGIDEV2 that fully understand it.

Yep, I've actually written many articles and a training manual years ago on
it. I've done hundreds of projects using it over that past 15+ years, as
well as our eRPG SDK. I'm very familiar with it. Probably more than most.

In fact, I was so familiar with it I wrote my own similar solution (eRPG
SDK) that I find more intuitive (personally) and executes much faster. I
liked the concept of CGIDEV2, but I didn't like how a few things were
implemented and decided to roll my own (since I already had everything from
all my other CGI programming articles and books).

But you knew that. :)

Brad
www.bvstools.com