One of our customers currently on VSI VMS on Integrity has been using
the GSOAP kit from HP as a client to communicate with a third party app
on windows server. The company making that product is dropping
SOAP/GSOAP and moving to only support JSON-based Restful API.

I see several items that purport to provide a Restful API for 'server'
side use on VMS, like WSIT from VSI. Client mentions seem to be
relegated to other platforms. Other options seem to be the same; server
only.

Are there any packages, callable libraries, "Netlib" like options, etc
that would allow VMS programs to access restful API servers? Whether
its encapsulation like the GSOAP kits, or just linking in a callable
library of routines?

Major props if it can be called from BASIC without intervening C or
other language.

Is VMS Python an option since it looks like Restful API is supported by
recent versions of that language on VMS? I assume we'd have to get
BASIC to talk to Python to do the communications in that case...

Thanks for any suggestions or info.

On Wed, 13 Mar 2024 17:34:13 -0500, Richard Jordan wrote:

> Is VMS Python an option since it looks like Restful API is supported by
> recent versions of that language on VMS?

REST is just HTTP under another name.

On 3/13/24 5:34 PM, Richard Jordan wrote:
> One of our customers currently on VSI VMS on Integrity has been using
> the GSOAP kit from HP as a client to communicate with a third party app
> on windows server.  The company making that product is dropping
> SOAP/GSOAP and moving to only support JSON-based Restful API.
>
> I see several items that purport to provide a Restful API for 'server'
> side use on VMS, like WSIT from VSI.  Client mentions seem to be
> relegated to other platforms.  Other options seem to be the same; server
> only.
>
> Are there any packages, callable libraries, "Netlib" like options, etc
> that would allow VMS programs to access restful API servers?  Whether
> its encapsulation like the GSOAP kits, or just linking in a callable
> library of routines?
>
> Major props if it can be called from BASIC without intervening C or
> other language.
>
> Is VMS Python an option since it looks like Restful API is supported by
> recent versions of that language on VMS?  I assume we'd have to get
> BASIC to talk to Python to do the communications in that case...
>
> Thanks for any suggestions or info.

There are basically two pieces to this:

1.) send the GET/POST/PUT/PATCH requests to the HTTP(S) endpoints
2.) parse the JSON that comes back

If you're particularly desperate, you can just use curl to send the
requests and dump the results to something (temp file or whatever), and
then parse the JSON somehow, perhaps with DCL if showing the kids how
things were done in the old days is the main goal. There are currently
better options.

There are plenty of capabilities with both Perl and Python to do #1 and
#2 together. Java too. To do it in BASIC you might need two libraries,
one for HTTP and one for JSON, or one library that does both, and those
libraries would probably be written in C and need wrappers for those
BASIC dynamic strings. Quite likely libcurl has everything you need,
though I've never actually done this kind of implementation with it.

VSI seems to be using Lua for some of its REST API implementations such
as the current web management product. I have no experience with it but
it's yet another way to do the HTTP thing with VMS as the client.

On Wed, 13 Mar 2024 18:28:42 -0500, Craig A. Berry wrote:

> If you're particularly desperate, you can just use curl to send the
> requests and dump the results to something (temp file or whatever), and
> then parse the JSON somehow ...

I would use wget rather than curl (simpler tool with less of a potential
attack surface).

JSON can be manipulated/parsed/generated from the command line using jq
<https://manpages.debian.org/1/jq.en.html>.

On 3/13/2024 6:34 PM, Richard Jordan wrote:
> One of our customers currently on VSI VMS on Integrity has been using
> the GSOAP kit from HP as a client to communicate with a third party app
> on windows server.  The company making that product is dropping
> SOAP/GSOAP and moving to only support JSON-based Restful API.
>
> I see several items that purport to provide a Restful API for 'server'
> side use on VMS, like WSIT from VSI.  Client mentions seem to be
> relegated to other platforms.  Other options seem to be the same; server
> only.
>
> Are there any packages, callable libraries, "Netlib" like options, etc
> that would allow VMS programs to access restful API servers?  Whether
> its encapsulation like the GSOAP kits, or just linking in a callable
> library of routines?
>
> Major props if it can be called from BASIC without intervening C or
> other language.
>
> Is VMS Python an option since it looks like Restful API is supported by
> recent versions of that language on VMS?  I assume we'd have to get
> BASIC to talk to Python to do the communications in that case...

I know of some options for client for RESTful web services:
* Java with any HTTP client including builtin HttpURLConnection
and any JSON library including GSon
* Python with request and json modules
* PHP with curl extension and json_encode/json_decode
* native code with plain sockets and some JSON library
like cJSON

There are code examples for client in Java, Groovy, Python,
PHP, C and Pascal here:
https://www.vajhoej.dk/arne/articles/vmsipc.html#rest

I guess I could come up with a Basic example similar to
the Pascal example.

But else:

Basic program--(binary/socket)--Java/Groovy/Python gateway
program--(JSON/HTTP)-->web service

should not be that bad.

Arne

On 3/13/2024 6:53 PM, Lawrence D'Oliveiro wrote:
> On Wed, 13 Mar 2024 17:34:13 -0500, Richard Jordan wrote:
>> Is VMS Python an option since it looks like Restful API is supported by
>> recent versions of that language on VMS?
>
> REST is just HTTP under another name.

No.

A RESTful web service will always use HTTP as transport
protocol, but not all web services using HTTP as protocol
are RESTful.

RESTful implies a lot about data model, URL format and
the use of HTTP methods.

Arne

On Wed, 13 Mar 2024 20:43:35 -0400, Arne Vajhøj wrote:

> RESTful implies a lot about data model, URL format and the use of HTTP
> methods.

So does HTTP.

On Wed, 13 Mar 2024 20:39:42 -0400, Arne Vajhøj wrote:

> * Java with any HTTP client including builtin HttpURLConnection

I don’t think that does any cookie management
<https://docs.oracle.com/en%2Fjava%2Fjavase%2F11%2Fdocs%2Fapi%2F%2F/java.base/java/net/HttpURLConnection.html>.
So if you want session authentication, you will need to do things in a
more complicated way.

On 3/13/2024 8:39 PM, Arne Vajhøj wrote:
> On 3/13/2024 6:34 PM, Richard Jordan wrote:
>> One of our customers currently on VSI VMS on Integrity has been using the
>> GSOAP kit from HP as a client to communicate with a third party app on windows
>> server. The company making that product is dropping SOAP/GSOAP and moving to
>> only support JSON-based Restful API.
>>
>> I see several items that purport to provide a Restful API for 'server' side
>> use on VMS, like WSIT from VSI. Client mentions seem to be relegated to other
>> platforms. Other options seem to be the same; server only.
>>
>> Are there any packages, callable libraries, "Netlib" like options, etc that
>> would allow VMS programs to access restful API servers? Whether its
>> encapsulation like the GSOAP kits, or just linking in a callable library of
>> routines?
>>
>> Major props if it can be called from BASIC without intervening C or other
>> language.
>>
>> Is VMS Python an option since it looks like Restful API is supported by recent
>> versions of that language on VMS? I assume we'd have to get BASIC to talk to
>> Python to do the communications in that case...
>
> I know of some options for client for RESTful web services:
> * Java with any HTTP client including builtin HttpURLConnection
> and any JSON library including GSon
> * Python with request and json modules
> * PHP with curl extension and json_encode/json_decode
> * native code with plain sockets and some JSON library
> like cJSON
>
> There are code examples for client in Java, Groovy, Python,
> PHP, C and Pascal here:
> https://www.vajhoej.dk/arne/articles/vmsipc.html#rest
>
> I guess I could come up with a Basic example similar to
> the Pascal example.
>
> But else:
>
> Basic program--(binary/socket)--Java/Groovy/Python gateway
> program--(JSON/HTTP)-->web service
>
> should not be that bad.
>
> Arne
>
>

I have some code that does an HTTPS POST written in Basic. Also have some code
that does a DNS lookup from VMS. Available to whoever asks.

Note, the code uses some code written in C. Some things I don't know how to do
from Basic.

As for Restful, I have no experience. But if you do the POST, you then have the
reply which can be parsed and used.

Never seen any reason to use a bunch of overhead to do a simple operation.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 3/13/2024 9:57 PM, Lawrence D'Oliveiro wrote:
> On Wed, 13 Mar 2024 20:39:42 -0400, Arne Vajhøj wrote:
>> * Java with any HTTP client including builtin HttpURLConnection
>
> I don’t think that does any cookie management
> <https://docs.oracle.com/en%2Fjava%2Fjavase%2F11%2Fdocs%2Fapi%2F%2F/java.base/java/net/HttpURLConnection.html>.
> So if you want session authentication, you will need to do things in a
> more complicated way.

It does not handle cookies automatically.

But since RESTful web services should not use session cookies,
then that is not really a problem.

Arne

On 3/13/2024 10:19 PM, Dave Froble wrote:
> On 3/13/2024 8:39 PM, Arne Vajhøj wrote:
>> There are code examples for client in Java, Groovy, Python,
>> PHP, C and Pascal here:
>>   https://www.vajhoej.dk/arne/articles/vmsipc.html#rest
>>
>> I guess I could come up with a Basic example similar to
>> the Pascal example.
>>
>> But else:
>>
>> Basic program--(binary/socket)--Java/Groovy/Python gateway
>> program--(JSON/HTTP)-->web service
>>
>> should not be that bad.
>
> I have some code that does an HTTPS POST written in Basic.  Also have
> some code that does a DNS lookup from VMS.  Available to whoever asks.
>
> Note, the code uses some code written in C.  Some things I don't know
> how to do from Basic.

I got something like that as well.

https://www.vajhoej.dk/arne/articles/vmsipc.html#http_wrap

https://www.vajhoej.dk/arne/articles/vmstd12.html#bas

> As for Restful, I have no experience.  But if you do the POST, you then
> have the reply which can be parsed and used.

With REST you sometimes chose to ignore the body in the reply to POST.

The REST convention for POST is that the request body contains the
new item to be added to collection and the reply body contain the
same item with any attributes added server side. But if the server
side is not adding any attributes, then there is no need to parse
the reply body as it then just contains the same as in the request
body.

Arne

On Wed, 13 Mar 2024 22:19:39 -0400, Arne Vajhøj wrote:

> But since RESTful web services should not use session cookies ...

Why not? It’s a valid form of authentication.

On 3/13/2024 10:45 PM, Lawrence D'Oliveiro wrote:
> On Wed, 13 Mar 2024 22:19:39 -0400, Arne Vajhøj wrote:
>> But since RESTful web services should not use session cookies ...
>
> Why not? It’s a valid form of authentication.

Sessions is a great idea for browsers communicating
with web applications. Session cookies may not be that
great, but they are better than the alternative URL
rewriting to support sessions.

But web services in general are different. RESTful web
services are very different. There is no general
purpose browser but a specific client application.
A RESTful service is stateless so it cannot keep a
session server side. Frequently the authorizing service
is different from the authorized service for modern web
services. Session cookies are not an option in that context.
There are plenty of alternatives. I believe that HTTP Authorization
header with "Bearer" type and JWT tokens are common.

Arne

On Thu, 14 Mar 2024 20:29:21 -0400, Arne Vajhøj wrote:

> A RESTful service is stateless so it cannot keep a
> session server side.

Who says it can’t?

> Frequently the authorizing service
> is different from the authorized service for modern web
> services. Session cookies are not an option in that context.

If a REST client is not a web browser, it doesn’t have to abide by web
browser security restrictions.

On 3/14/2024 9:31 PM, Lawrence D'Oliveiro wrote:
> On Thu, 14 Mar 2024 20:29:21 -0400, Arne Vajhøj wrote:
>> A RESTful service is stateless so it cannot keep a
>> session server side.
>
> Who says it can’t?

Fielding.

<quote>
5.1.3 Stateless

We next add a constraint to the client-server interaction: communication
must be stateless in nature, as in the client-stateless-server (CSS)
style of Section 3.4.3 (Figure 5-3), such that each request from client
to server must contain all of the information necessary to understand
the request, and cannot take advantage of any stored context on the
server. Session state is therefore kept entirely on the client.
</quote>

>> Frequently the authorizing service
>> is different from the authorized service for modern web
>> services. Session cookies are not an option in that context.
>
> If a REST client is not a web browser, it doesn’t have to abide by web
> browser security restrictions.

The client can do anything it wants to.

But using browser cookie HTTP headers for implementing
a different semantics than browsers do is the worst possible
design. Standards are good. Hacks are bad. Hacks that pretend
to look like standards are the worst.

Arne

On Thu, 14 Mar 2024 22:27:05 -0400, Arne Vajhøj wrote:

> On 3/14/2024 9:31 PM, Lawrence D'Oliveiro wrote:
>
>> On Thu, 14 Mar 2024 20:29:21 -0400, Arne Vajhøj wrote:
>>
>>> A RESTful service is stateless so it cannot keep a
>>> session server side.
>>
>> Who says it can’t?
>
> Fielding.

Who is this “Fielding”?

>> If a REST client is not a web browser, it doesn’t have to abide by web
>> browser security restrictions.
>
> The client can do anything it wants to.
>
> But using browser cookie HTTP headers for implementing
> a different semantics than browsers do is the worst possible
> design.

Who says it has “different semantics than browsers do”?

On 3/14/2024 11:10 PM, Lawrence D'Oliveiro wrote:
> On Thu, 14 Mar 2024 22:27:05 -0400, Arne Vajhøj wrote:
>> On 3/14/2024 9:31 PM, Lawrence D'Oliveiro wrote:
>>> On Thu, 14 Mar 2024 20:29:21 -0400, Arne Vajhøj wrote:
>>>> A RESTful service is stateless so it cannot keep a
>>>> session server side.
>>>
>>> Who says it can’t?
>>
>> Fielding.
>
> Who is this “Fielding”?

Roy Fielding - the guy that defined REST.

Arne

On Fri, 15 Mar 2024 09:13:16 -0400, Arne Vajhøj wrote:

> On 3/14/2024 11:10 PM, Lawrence D'Oliveiro wrote:
>>
>> On Thu, 14 Mar 2024 22:27:05 -0400, Arne Vajhøj wrote:
>>>
>>> On 3/14/2024 9:31 PM, Lawrence D'Oliveiro wrote:
>>>>
>>>> On Thu, 14 Mar 2024 20:29:21 -0400, Arne Vajhøj wrote:
>>>>>
>>>>> A RESTful service is stateless so it cannot keep a session server
>>>>> side.
>>>>
>>>> Who says it can’t?
>>>
>>> Fielding.
>>
>> Who is this “Fielding”?
>
> Roy Fielding - the guy that defined REST.

I would say his original vision suffered from ... a lack of imagination.

On Fri, 15 Mar 2024 20:56:45 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> On Fri, 15 Mar 2024 09:13:16 -0400, Arne Vajhøj wrote:
>
> > On 3/14/2024 11:10 PM, Lawrence D'Oliveiro wrote:
> >>
> >> On Thu, 14 Mar 2024 22:27:05 -0400, Arne Vajhøj wrote:
> >>>
> >>> On 3/14/2024 9:31 PM, Lawrence D'Oliveiro wrote:
> >>>>
> >>>> On Thu, 14 Mar 2024 20:29:21 -0400, Arne Vajhøj wrote:
> >>>>>
> >>>>> A RESTful service is stateless so it cannot keep a session
> >>>>> server side.
> >>>>
> >>>> Who says it can’t?
> >>>
> >>> Fielding.
> >>
> >> Who is this “Fielding”?
> >
> > Roy Fielding - the guy that defined REST.
>
> I would say his original vision suffered from ... a lack of
> imagination.

I'd guess that limitation of the damage caused by too imaginative
developers was the main point behind REST.

On Sun, 17 Mar 2024 12:09:23 +0200, Michael S wrote:

> I'd guess that limitation of the damage caused by too imaginative
> developers was the main point behind REST.

Some of us noticed that REST is just a rebranding of HTTP, and are
treating it accordingly.

On 3/13/24 5:34 PM, Richard Jordan wrote:
> One of our customers currently on VSI VMS on Integrity has been using
> the GSOAP kit from HP as a client to communicate with a third party app
> on windows server.  The company making that product is dropping
> SOAP/GSOAP and moving to only support JSON-based Restful API.
>
> I see several items that purport to provide a Restful API for 'server'
> side use on VMS, like WSIT from VSI.  Client mentions seem to be
> relegated to other platforms.  Other options seem to be the same; server
> only.
>
> Are there any packages, callable libraries, "Netlib" like options, etc
> that would allow VMS programs to access restful API servers?  Whether
> its encapsulation like the GSOAP kits, or just linking in a callable
> library of routines?
>
> Major props if it can be called from BASIC without intervening C or
> other language.
>
> Is VMS Python an option since it looks like Restful API is supported by
> recent versions of that language on VMS?  I assume we'd have to get
> BASIC to talk to Python to do the communications in that case...
>
> Thanks for any suggestions or info.

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.

On 3/20/2024 12:05 AM, Richard Jordan wrote:
> On 3/13/24 5:34 PM, Richard Jordan wrote:
>> One of our customers currently on VSI VMS on Integrity has been using
>> the GSOAP kit from HP as a client to communicate with a third party
>> app on windows server.  The company making that product is dropping
>> SOAP/GSOAP and moving to only support JSON-based Restful API.
>>
>> I see several items that purport to provide a Restful API for 'server'
>> side use on VMS, like WSIT from VSI.  Client mentions seem to be
>> relegated to other platforms.  Other options seem to be the same;
>> server only.
>>
>> Are there any packages, callable libraries, "Netlib" like options, etc
>> that would allow VMS programs to access restful API servers?  Whether
>> its encapsulation like the GSOAP kits, or just linking in a callable
>> library of routines?
>>
>> Major props if it can be called from BASIC without intervening C or
>> other language.
>>
>> Is VMS Python an option since it looks like Restful API is supported
>> by recent versions of that language on VMS?  I assume we'd have to get
>> BASIC to talk to Python to do the communications in that case...
>>
>> Thanks for any suggestions or info.
>
> 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

From the client programming perspective it does not matter whether
the HTTP goes over 1000 inches of wire or 1000 miles of wire.

External cloud means that the network team need to open the firewalls
for this specific outbound traffic, but they must be doing that for
other traffic already so no big deal.

> with no reasonable option to set
> up a test account so we can create the software to talk to it on VMS.

No test system is a problem.

But:
* "usually" documentation for RESTful web services contains request
and response examples and if this one does then creating a server
simulator is easy
* a "well behaved" RESTful service does not change any state for
GET requests, so if that is the case then GET requests can be tested
against the real server (unless data privacy prevents test on real
data)

And this problem is not VMS specific. Any client in any language on
any OS will have this problem.

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

If you just need to play a little with RESTful web service then
any system is fine to host including your VMS system.

> More likely we'll end up with some middleware on a local pc server
> talking to the vendor cloud, and relaying requests from VMS.

That is obviously possible.

But that middleware could run on VMS as well.

Running on those Linux/Windows server greatly increases the
number of tools/frameworks/libraries available, but it could
run on VMS.

Arne

On 3/20/2024 12:05 AM, Richard Jordan wrote:
> On 3/13/24 5:34 PM, Richard Jordan wrote:
>> One of our customers currently on VSI VMS on Integrity has been using the
>> GSOAP kit from HP as a client to communicate with a third party app on windows
>> server. The company making that product is dropping SOAP/GSOAP and moving to
>> only support JSON-based Restful API.
>>
>> I see several items that purport to provide a Restful API for 'server' side
>> use on VMS, like WSIT from VSI. Client mentions seem to be relegated to other
>> platforms. Other options seem to be the same; server only.
>>
>> Are there any packages, callable libraries, "Netlib" like options, etc that
>> would allow VMS programs to access restful API servers? Whether its
>> encapsulation like the GSOAP kits, or just linking in a callable library of
>> routines?
>>
>> Major props if it can be called from BASIC without intervening C or other
>> language.
>>
>> Is VMS Python an option since it looks like Restful API is supported by recent
>> versions of that language on VMS? I assume we'd have to get BASIC to talk to
>> Python to do the communications in that case...
>>
>> Thanks for any suggestions or info.
>
> 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?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

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

On 3/20/2024 1:52 PM, Stephen Hoffman wrote:
> 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.

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

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

Side note: Java is also a relevant choice on VMS. Or more
accurate: JVM languages are also a relevant choice on VMS,
if one happens to like Groovy or Kotlin or Scala better than
Java (I suspect Groovy is most relevant for the task).

It is true that the traditional/native VMS languages
are not good at this.

But one should note that on Windows/Linux then the
majority of this type of stuff is not done in
native code either, but in Java/Groovy/Kotlin/Scala, Python,
PHP, C#/VB.NET etc..

It is not just that VMS RTL's does not come with
builtin HTTP(S) and JSON support, but just as much
that VMS applications are almost entirely in native code
while on other platforms the majority of business
applications are now in non-native code.

Arne