Is VMS Python an option since it looks like Restful API is supported by recent versions of that language on VMS?
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.
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 ...
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.
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...
RESTful implies a lot about data model, URL format and the use of HTTP methods.
* Java with any HTTP client including builtin HttpURLConnection
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:
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.
As for Restful, I have no experience. But if you do the POST, you then
have the reply which can be parsed and used.
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
But since RESTful web services should not use session cookies ...
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.
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.
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.
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.
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 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”?
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.
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.
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 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/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:
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?
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.
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/17/2024 5:07 PM, Lawrence D'Oliveiro wrote:
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.
REST is a rebranding of HTTP in the same sense that
SUV's are a rebranding of tires.
On 3/17/2024 5:07 PM, Lawrence D'Oliveiro wrote:
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.
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.
On 3/17/2024 5:07 PM, Lawrence D'Oliveiro wrote:
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.
This annoyance particularly when we remember VAX/VMS was once the box
that was commonly used to connect everything else together.
Python and some other choices are likely the furthest along for this
general REST task ...
Java is also a relevant choice on VMS.
In article <utfajh$1kqvi$2@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
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.
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?
He is happily winding up the folk in comp.lang.ada, amongst others
On 2024-03-20, Chris Townley <news@cct-net.co.uk> wrote:
He is happily winding up the folk in comp.lang.ada, amongst others
I have noticed that. I think Dan is right about him.
The SAX-style parser model has long since
been left behind as an acceptable way to parse JSON/XML/etc...
On Thu, 2024-03-21 at 13:08 +0000, Simon Clubley wrote:
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 :-<
On 2024-03-20, Dave Froble <davef@tsoft-inc.com> wrote:
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.
On 2024-03-21, Single Stage to Orbit <alex.buell@munted.eu> wrote:
On Thu, 2024-03-21 at 13:08 +0000, Simon Clubley wrote:
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.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 434 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 116:17:30 |
| Calls: | 9,109 |
| Calls today: | 3 |
| Files: | 13,419 |
| Messages: | 6,030,483 |