Check out this intro to HDA (Hypermedia-Driven Applications);
This seems relevant to the ongoing discussions about C2S APIs for the fediverse, especially the proliferation of the monolithic server+web-app antipattern. If Daz (@daz@social.coop) is correct, properly RESTful APIs that use an HDA architecture might be a way to realise Christine Webber’s original vision. Fediverse web apps with specific purposes, like browsing and posting video, as ways to login to generic AP servers hosting general-purpose accounts.
This seems particularly important for making fediverse development accessible to more people, and lowering the workload of ongoing maintenance;
“This is the core durability argument for HDA. Your investment in HTML templates, HTTP handlers, and declarative interactivity attributes is protected by the strongest backward-compatibility commitment in software: the web platform’s refusal to break existing content.”
Working with HTMX, I’ve fallen in love with REST all over again. And yes, I think this could be a very important part of a future ActivityPub API. One of may issues with C2S at the moment is that it puts so much responsibility on the client application to know what is or isn’t supported on the server. This would be fine for a “generic” ActivityPub server that simple stores and forwards data, but doesn’t parse or understand it. However, if the point of the AP server is also to generate a website (or app view) then it needs to make assumptions about the data it’s holding.
A RESTful architecture would allow the server to provide a catalog of the kinds of data that could be stored on it, along with (for example) a JSON-schema or JSON-forms view of data that can be used with each kind of transaction.
This would probably be an uphill battle with the existing architecture. A lot of the current architectural thinking is about those “generic” servers. But if we want to go down this road, it would make sense to make a proposal with specific data examples and a use case or two. We would also need to show how it could be backwards compatible with current server designs, and how a “generic” server might still work without conflicting with a truly RESTful one.
Can’t this be done in an AP client that is itself an application running on a “server”? There’s no need to force monolithic architectures on generic servers that store-and-forward.
It sounds like you are describing Solid. Solid uses HTTP verbs directly (POST, PUT, DELETE) to manage resources in a RESTful way.