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.

Arne

On 3/20/2024 2:40 PM, Arne Vajhøj wrote:
> 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.

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

In article <utfajh$1kqvi$2@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>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.

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.

On Wed, 20 Mar 2024 14:40:48 -0400, Arne Vajhøj wrote:

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

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

On Wed, 20 Mar 2024 14:45:53 -0400, Arne Vajhøj wrote:

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

On Wed, 20 Mar 2024 14:23:13 -0400, Arne Vajhøj wrote:

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

On Wed, 20 Mar 2024 13:52:16 -0400, Stephen Hoffman wrote:

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

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

On 20/03/2024 19:02, Dan Cross wrote:
> 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.

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

--
Chris

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. The SAX-style parser model has long since
been left behind as an acceptable way to parse JSON/XML/etc...

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

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.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

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 :-<
--
Tactical Nuclear Kittens

On Thu, 2024-03-21 at 13:10 +0000, Simon Clubley wrote:
> 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.

He's also in the raspberry pi groups too.
--
Tactical Nuclear Kittens

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.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 3/21/2024 9:08 AM, Simon Clubley wrote:
> 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.

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

On 3/21/2024 2:21 PM, Simon Clubley wrote:
> 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.

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

On Thu, 2024-03-21 at 18:21 +0000, Simon Clubley wrote:
> > 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.
--
Tactical Nuclear Kittens