when I glance over your words I hear the sentence you've written in my mind's ear - even though tongues were never made for speaking - we LITERALLY use an organ that is for chewing and swallowing food, and using it to talk with, which we can only do while our mouth isn't doing what it's actually built for, which is to chew and swallow!

And that's what we choose to imitate to communicate with each other? A hack on top of a hack!!! Why should I write something that makes you hear in your mind's ear my chewing organ fashioning air.

Wouldn't it be a lot better to ACTUALLY communicate with you some kind of direct meaning, rather than trying to jury-rig an entire civilization on top of imitations of flapping meat? Plus, the spelling is linked with the meaning anyway, if I had misspelled "meat" as "meet" just now you would have been confused! So why not take away the part where you're hearing this in your mind's ear, and just communicate!

blah blah blah. In other words, it doesn't matter what "INFRASTRUCTURE IS". A two year old's infrastructure for language is a mouth organ that they also eat with. It's OBVIOUSLY a design wart. This is completely obvious.

It also works. Gmail is fine and fun to use, even though as I type a to: field it predicts the address. Not something a stateless document-centric infrastructure was designed to do.

Oh well. It's called progress and civilization. It doesn't matter if it starts with flapping a chewing organ, and then imitating a poor abstraction of that through writing. who cares!

This is the crux of the matter. Surprised how few of the comments which addresses this.

Just look at how many JS frameworks which have a "router" component. So rather than navigating documents you end up faking that we navigate documents. Wonder why things are getting so hard?

Look at how many have difficulties in distinguishing what REST is supposed to be and RPC. Both have a place - but many look for the "one" solution and ends up using something they call REST in a RPC style.

Just a nitpick, but stateless/stateful are descriptions applied to protocols not applications. The mechanics of persisting application context between request/response events might be contentious and varied in web applications, but just because the protocol is stateless doesn't necessarily mean that your application is more difficult to maintain.

I agree with your point, but it is begging the question: are we overlooking the value/potential that a generation of developers found in the stateless nature of HTTP?