[Info-vax] Restful API w/JSON client package or library on OpenVMS

[Stephen Hoffman]

On 2024-03-20 16:00:39 +0000, Dave Froble said:

> On 3/20/2024 12:05 AM, Richard Jordan wrote:
>> 
>> Thanks for the responses.  Got a little more info; where the current 
>> GSoap implementation is done to the vendor software running on a local 
>> server; the new one is cloud (O frabjous day! Callooh! Callay!) so the 
>> connection is done to a public server with no reasonable option to set 
>> up a test account so we can create the software to talk to it on VMS.
>> 
>> I may find something that can run as a generic server on one of the 
>> customer's pc servers so we can test doing 'generic' restful but we'll 
>> see. More likely we'll end up with some middleware on a local pc server 
>> talking to the vendor cloud, and relaying requests from VMS.
> 
> Well, not sure how much you want to get into things.  But, if you're 
> going to implement something, why put some PC in the middle of things.  
> It's rather simple to do from VMS.
> 
> At the bottom of whatever is used is, wait for it, a socket.  Simple 
> socket communications.  Add SSL/TLS for encryption.
> 
> I'm not looking at your requirements, but, I'd bet that HTTPS is used.  
> After that, it's just what happens to the data.
> 
> Isn't data manipulation what we do?

The source of annoyance for some reading here is that the available 
native libraries are somewhere between unhelpful and ineffective, just 
as soon as you need to interoperate with most anything else from the 
past decade or two. Yeah, I can do all of this in VAX MACRO32 too, but 
~nobody willingly chooses that path.

This annoyance particularly when we remember VAX/VMS was once the box 
that was commonly used to connect everything else together. Too many of 
us are now using other boxes to network OpenVMS to anything else. Use 
of a middle box is already discussed in this thread, too.

Python and some other choices are likely the furthest along for this 
general REST task, but the "traditional" OpenVMS languages and OpenVMS 
RTLs are pre-millennially-less-than-entirely-useful, at best. As Dave 
is well aware, TLS support is trailing, too.

In this case, lib$table_parse would be one path for rolling your own 
communications implementation locally.

libcurl might be interesting and useful here within the lib$table_parse 
action routines or within the context of some other finite state 
machine, if not using TLS directly.

Some libcurl examples: https://curl.se/libcurl/c/http-post.html and 
https://curl.se/libcurl/c/https.html and ilk, and some options: 
https://curl.se/libcurl/competitors.html

cJSON was ported: https://www.vajhoej.dk/arne/opensource/ and JSON-C is 
reportedly easily ported: https://github.com/json-c/json-c

Definitely go with a FSM design, here. Trying to code these tasks using 
a OpenVMS classic procedural imperative style (and particularly without 
an FSM) and nested if and the rest (no pun intended) just gets ugly and 
gnarly.

The whole OpenVMS development environment is unfortunately far too 
close to using a crayon in recent years, as compared with other 
platform choices.  But then, lib$table_parse is certainly one of the 
remaining very useful built-in features.

The network connection testing here can potentially use MITMProxy or 
ilk, assuming the remote server doesn't have a sandbox for testing 
apps.  https://mitmproxy.org  You'll need to load some certificates to 
allow MITMProxy access into the connection.

Porting Apache Serf and Apache APR via VSI SWS might be an alternative 
to libcurl, but that's almost certainly going to be more involved 
porting than using libcurl. And libcurl is already ported: 
https://vmssoftware.com/products/curl/

Or use that middle box, of course.


-- 
Pure Personal Opinion | HoffmanLabs LLC