i even thought SOAP was quite nice if you used the message oriented flavour instead of RPC flavour. REST was imo better and won out, but then nobody really does REST today and we seem to keep on re-inventing the wheel. am watching the htmx discourse with interest.
if your web service had a truly RESTful design then all you would need to do is point something like postman (or a browser) at it and it would be able to automagically figure out the whole set of available resources and interactions instead of having to use all this crazy swagger/OpenAPI stuff. there's a whole cottage industry around this api stuff rn.
i guess this is what happens when you put "programmers" in charge of a hypermedia system. everything becomes an RPC and nothing is standardised.
¯\_(ツ)_/¯
i'm intrigued by the combination of Assembly and XSL - any pointers to what you use those for?
Even in its neglected state, it's got tons of features. You know how when Hacker News is having server issues, it tends to still work when logged out? Well you can just always serve the logged out page so it's cached for everyone, and then in the xslt template you can do an include of the user's data (that's right, you can directly include and query other xml documents in xhtml/xslt), e.g. <xsl:variable name="myinfo" select="document('/app/users/myinfo')"/> or something, and set that URL to private cache or no-cache, and then in the parts where you need the page to be different for the logged in user, you can e.g. compare '$myinfo/user/@id' to '@authorId' of a comment to decide whether to show an edit/delete button, etc. You basically get graceful degradation by default if it can't fetch that myinfo document. XPath is like jq that's been built into the browser this whole time.
The same thing can be used for things like subreddit side bars that are common across many but not all pages. You can even do an xsl:copy-of and serve it as xhtml. No need to send the same data over and over with SSR. No need to do client side routing or have any frontend tooling. It's all built right into the browser. The code is concise (it's verbose in the sense that it's xml, but it's still declarative) and easy to read. You can have a clean separation between backend sending the data in an xml model that makes sense for the domain, and then frontend having templates to present it.
The downside is of course that it all runs before the html for your page is produced, so you can't use javascript inside of xsl (unless you run a separate xsl processor in javascript), and it's about the same as SSR in terms of how dynamic it is (i.e. not interactive after page load, though you can of course have javascript in the output html). That and there's no info out there about how to use it because no one uses it, so you have to be a little creative. But it's been quite fun to see how much I can milk out of client side static template rendering using a technology that browsers haven't even bothered to update past 1.0 from 1999.
Maybe what's needed is an extension to XSLT/XPath to consume JSON and transform it to XML.
it would be nice to see if fundamental xml tech can be improved in a new hardware and software environment. afaik, there hasn't been much if any innovation in that space in recent times. would love to know if there has.
The first time I encountered XSLT I thought it was the most ridiculous thing to ever have been invented. A programming language written in XML?
but damn, the things you can do with that thing in a tiny bit of code. It was doing expression filtering years before anyone else, including the likes of Haskell.
I remember installing enterprise java beans to support my soap wsdl 16 years ago. Meanwhile shopify built a basic Rails app using http verbs and killed the product I was using.