Re: http_post consumer API calls in a mass volume situation

[Charles Wilt <charles.wilt@xxxxxxxxx>]

Given a "large volume", I'd probably stay away from http_post.

I've used Scott's HTTP API to send 1000's of requests per minute to an AWS
Lambda. Using a persistent connection (especially when dealing with
SSL/TLS) saves a considerable amount of time.  In that case, the business
apps wrote to a queue and there was a set of 3 RPG jobs reading from the
queue and sending the data out.

I've also written a RPG handler program that used HTTP API to redirect RPG
writes to a web service...though that never ended up getting turned on in
production AFAIK.

Assuming your apps don't need to wait for a result, then the queue type
solution is likely your best bet.

You might also want to take a look at Apache Camel and/or Kafka.
Jesse Gorzinski has a number of presentations/articles about using them.

Good place to start
https://www.youtube.com/watch?v=8qVfw6KR2ww

HTH,
Charles



On Tue, Mar 11, 2025 at 11:06 AM Jay Vaughn <jeffersonvaughn@xxxxxxxxx>
wrote:

> Let me start with just a pretty generic question and scenario.
>
> If you had a need to send a large volume of http API consumer requests
> from your native applications (and db2)... is it correct to think that
> http_post may not exactly be the best choice as it is real time
> synchronous...
> If so,  what are some other good options?
>
> Or am I wrong?  Could you expect http_post to hold up.
>
> Pretty speculative scenario I realize - but imagine a level of volume that
> you may consider moderate to high even for your native applications to go
> after db2 data locally - but instead, those "i/o"s are considering to be
> replaced with http_post to another system.
> As a change occurs  in the application, that change is pushed over off
> platform via http via the http_post...
>
> can it work?
> what are the considerations?
> Also this would be with https (ssl authentication in play)
>
> tia
>
> jay
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: https://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at https://archive.midrange.com/midrange-l.
>
> Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
> questions.