Restful API w/JSON client package or library on OpenVMS

[Richard Jordan]

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.

[Lawrence D'Oliveiro]

Post by Richard Jordan
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.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Richard Jordan
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

[Lawrence D'Oliveiro]

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

So does HTTP.

[Craig A. Berry]

Post by Richard Jordan
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.

[Lawrence D'Oliveiro]

Post by Craig A. Berry
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>.

[Arne Vajhøj]

Post by Richard Jordan
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

[Lawrence D'Oliveiro]

Post by Arne Vajhøj
* 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.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
* 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

[Lawrence D'Oliveiro]

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

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

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

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

[Lawrence D'Oliveiro]

Post by Arne Vajhøj
A RESTful service is stateless so it cannot keep a
session server side.

Who says it can’t?

Post by Arne Vajhøj
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.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
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>

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
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

[Lawrence D'Oliveiro]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
A RESTful service is stateless so it cannot keep a
session server side.

Who says it can’t?

Fielding.

Who is this “Fielding”?

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro
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”?

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
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

[Lawrence D'Oliveiro]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

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.

[Michael S]

On Fri, 15 Mar 2024 20:56:45 -0000 (UTC)

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

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.

[Lawrence D'Oliveiro]

Post by Michael S
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.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Michael S
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.

REST is a rebranding of HTTP in the same sense that
SUV's are a rebranding of tires.

Arne

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by Michael S
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.

REST is a rebranding of HTTP in the same sense that
SUV's are a rebranding of tires.

Note that there are some slack in definition of RESTful web services.

purist developers : understand the concept and follows all conventions

pragmatic developers : understand the concept and follows conventions
where they think it makes sense and deviate where they think that
makes sense

marketing people & manager : call any web service based on JSON/HTTP
for RESTful no matter how much RPC style it is, because RESTful is
hot

And then we have the jokes. Calling REST a rebranding of HTTP is
not funny, but this one posted to LinkedIn is:

"Why is it called a REST API when it wakes me up at 3 AM to fix it?"

:-)

Arne

[Lawrence D'Oliveiro]

Post by Arne Vajhøj
Note that there are some slack in definition of RESTful web services.

Or, stay away from the loaded term altogether and just call it “HTTP”.

[Dan Cross]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by Michael S
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.

REST is a rebranding of HTTP in the same sense that
SUV's are a rebranding of tires.

Seriously, though: have you not realized by now that
this clown is unreasonable, and that by responding to
his uninformed missives, you're just wasting your time?

- Dan C.

[Chris Townley]

Post by Dan Cross
Seriously, though: have you not realized by now that
this clown is unreasonable, and that by responding to
his uninformed missives, you're just wasting your time?
- Dan C.

You woke the troll up!

That is one benefit of a modern forum - they can ban the trolls

He is happily winding up the folk in comp.lang.ada, amongst others

[Simon Clubley]

Post by Chris Townley
He is happily winding up the folk in comp.lang.ada, amongst others

I have noticed that. I think Dan is right about him.

Simon.

[Single Stage to Orbit]

Post by Simon Clubley

Post by Chris Townley
He is happily winding up the folk in comp.lang.ada, amongst others

I have noticed that. I think Dan is right about him.

He's also in the raspberry pi groups too.

[Lawrence D'Oliveiro]

Post by Lawrence D'Oliveiro
Some of us noticed that REST is just a rebranding of HTTP, and are
treating it accordingly.

REST is a rebranding of HTTP in the same sense that SUV's are a
rebranding of tires.

Considering that most “SUVs” are totally unsuited for use outside of urban
roads, that’s not too far off.

[Dave Froble]

Post by Arne Vajhøj

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

* 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,
https://www.vajhoej.dk/arne/articles/vmsipc.html#rest
I guess I could come up with a Basic example similar to
the Pascal example.
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.

[Arne Vajhøj]

Post by Arne Vajhøj
There are code examples for client in Java, Groovy, Python,
  https://www.vajhoej.dk/arne/articles/vmsipc.html#rest
I guess I could come up with a Basic example similar to
the Pascal example.
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

[Richard Jordan]

Post by Richard Jordan
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.

[Arne Vajhøj]

Post by Richard Jordan
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

[Dave Froble]

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?

[Stephen Hoffman]

Post by Dave Froble

Post by Richard Jordan
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.

[Arne Vajhøj]

Post by Stephen Hoffman

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

[Lawrence D'Oliveiro]

Post by Arne Vajhøj
Java is also a relevant choice on VMS.

Sure, if you’re going to beat your head against one obsolescent,
troublesome, limited platform, why not throw another one into the mix.

ObJavaRant:
<https://forums.theregister.com/forum/all/2024/03/19/catch_java_22_now_available/#c_4831452>

[Lawrence D'Oliveiro]

Post by Stephen Hoffman
This annoyance particularly when we remember VAX/VMS was once the box
that was commonly used to connect everything else together.

Surely that was no longer true after the 1980s ...

Post by Stephen Hoffman
Python and some other choices are likely the furthest along for this
general REST task ...

Running on a Linux platform, of course. Given the range of tools
available, that really is the easiest.

[Simon Clubley]

Post by Dave Froble
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?

Why is everyone focused on the HTTP part of the problem only ?

You also need a decent JSON library that allows you to turn the incoming
JSON into a data structure that you can make queries to and iterate over
its components as required. The SAX-style parser model has long since
been left behind as an acceptable way to parse JSON/XML/etc...

Simon.

[Single Stage to Orbit]

Post by Simon Clubley
The SAX-style parser model has long since
been left behind as an acceptable way to parse JSON/XML/etc...

I wish you hadn't mentioned that. SAX needs to do one :-<

[Simon Clubley]

Post by Single Stage to Orbit

Post by Simon Clubley
The SAX-style parser model has long since
been left behind as an acceptable way to parse JSON/XML/etc...

I wish you hadn't mentioned that. SAX needs to do one :-<

Sorry. :-) Did I bring back some trauma memories ? :-)

In the same way that we no longer write applications in assembly language,
I am just glad that SAX-style parsing isn't still the standard way of doing
things these days and that we now have libraries which can build a document
tree we can ask questions about and easily iterate through.

As mentioned above, there's a really good reason SAX has been left behind
as an acceptable method, because the alternatives are so much better.

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Single Stage to Orbit

Post by Simon Clubley
The SAX-style parser model has long since
been left behind as an acceptable way to parse JSON/XML/etc...

I wish you hadn't mentioned that. SAX needs to do one :-<

Sorry. :-) Did I bring back some trauma memories ? :-)
In the same way that we no longer write applications in assembly language,
I am just glad that SAX-style parsing isn't still the standard way of doing
things these days and that we now have libraries which can build a document
tree we can ask questions about and easily iterate through.
As mentioned above, there's a really good reason SAX has been left behind
as an acceptable method, because the alternatives are so much better.

SAX model is "streaming push" model.

There are 4 models for reading XML/JSON - in order from easiest to
use to most difficult to use:
* binding
* DOM tree
* streaming pull
* streaming push

Web services typical use binding if the language and library
supports it.

But I would not totally discard the streaming parsers.

They are needed if the XML/JSON can't be in memory. Not the
case for web services though.

And they are often used as foundation for the other models
(DOM trees and binding).

Arne

[Single Stage to Orbit]

Post by Simon Clubley

Post by Single Stage to Orbit
I wish you hadn't mentioned that. SAX needs to do one :-<

Sorry. :-) Did I bring back some trauma memories ? :-)
In the same way that we no longer write applications in assembly
language, I am just glad that SAX-style parsing isn't still the
standard way of doing things these days and that we now have
libraries which can build a document tree we can ask questions about
and easily iterate through.
As mentioned above, there's a really good reason SAX has been left
behind as an acceptable method, because the alternatives are so much
better.

Yes indeed.

[Arne Vajhøj]

Post by Simon Clubley

Post by Dave Froble
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?

Why is everyone focused on the HTTP part of the problem only ?
You also need a decent JSON library that allows you to turn the incoming
JSON into a data structure that you can make queries to and iterate over
its components as required.

Web service client and server consist of 4 problems.

One hard:
* HTTP server

Two medium:
* HTTP client
* reading JSON

One trivial:
* writing JSON

Most newer languages comes with HTTP and JSON support,
but the traditional VMS languages does not.

There are C libraries for reading JSON and
some of them build on VMS.

My preferred one is cJSON.

And I have VMS Pascal wrappers (I am calling it PJSON).

Writing wrappers in VMS Basic would not be that difficult.

Fortran and Cobol would probably be ugly - variable length
strings makes code simpler.

Arne