Using an RPC approach as you advocate carries with it all the poor architectural properties that RPC has always had, and will continue to have; poor visibility, poor scalability, poor self-description, poor reliability. While using REST is harder, because it is more constraining, you really need to consider the cost of those lost properties before you can suggest an alternative architectural style. Yes, it's easy to pick nits and find cases where RPC has a small advantage, but that doesn't in any way suggest that RPC is the best style for the system as a whole. On the contrary, I think RPC has demonstrated quite well over the past 20+ years that it's entirely unsuitable for the Internet, whereas REST has demonstrated the exact opposite.
Given the constraints of the column format, I think the "better approach" section makes a fair and accurate assessment of why REST isn't great. After all, the introspection file is just run-time WSDL.
Introspection says "post this kind of message here", where the message type is identified by the element name in the file, but defined out of band. "Post a resource" vs "post a schema-defined document" -- to me, the difference is theoretical; the cost described in the column. Time for me, I think, to give this debate a rest.
If you can't see the difference, or don't see it as important, then you're either not looking hard enough, or you don't understand the importance of constraints to software architecture.
Previous Message
