I didn't think that Kay's thinking was exactly the Smalltalk model. It is just that it was one feasible implementation with some key compromises thrown in. I do

I didn't think that Kay's thinking was exactly the Smalltalk model. It is just that it was one feasible implementation with some key compromises thrown in. I don't think he missed asynchronicity. Just that the machines of his time would've made it next to impossible to be purist about that. He is smart enough to see that the biological systems he was inspired by are asynchronous. In other words, the synchronicity of Smalltalk is somewhat accidental, with good benefits reaped from the idea of reified messages, which Smalltalk does have and C++ etc. don't. Erlang is indeed Smalltalk done right, but, as the OP wrote on the blog, it is not only about messaging and is about the additional constraints. We've seen REST principles used within a single computer in the AppleScript system and protocol, for example, where you could think of applications running on a single computer as being individual computers in their own right and you need to be able to manipulate them using messages that talk using representations of objects in these applications. For example, "window 1" could be a representation for the first window in an application according to some internal ordering in it. We also see REST-like interfaces at various system boundaries - for example, addressing textures on a GPU when preparing instructions on the host CPU. Databases too provide tables as resources and produce/consume representations of these tables to perform their functions. So it isn't surprising to see connectors to APIs exposed via ODBC or REST APIs to RDBMS tables as with PostgREST. So the "InProcess-REST" is in principle understandable as an application architecture pattern, though with the caveat that I haven't gone into the specifics of the OP's work on this (expensive book, etc.).