Sure, SOAP's complexity is a problem, but the issue with "RESTful" APIs is that they're so loosely defined, almost all the way to the other extreme. Being able to generate code and have a type-checked API, which is as easy to use as any other local API was a very nice feature we've now lost. I wish there were a better compromise.
I think we'll see more and more schema related projects for JSON-based API (like swagger). It will be interesting if they can compose in a way that keeps the complexity down, as opposed to what happened with SOAP.
* Originally, Google Protocol Buffers. These are still in wide use; unfortunately, they never published/blessed an official RPC stack.
* Apache Thrift, aka Facebook's answer to Protocol Buffers.
* Capn Proto, by one of the Protocol Buffers authors, now has an RPC standard!
After having used Protocol Buffers extensively, I could never go back to untyped APIs. I'd at least use Apache Thrift for everything. Hopefully Capn Proto gets more languages supported for its RPC soon.
Protocol Buffers is great. Thrift generates much nicer C++ code but performs slower and wants you to do everything inside their networking world. I'm excited for Cap'n Proto. It's a good time to be doing binary IPC.
I'm still uncertain about melding the message format and RPC mechanics though. Part of me feels like network communications is just too big of a deal to abstract away into something that looks like a normal procedure call. But hey, even if that's always true for big systems, it probably won't be for smaller apps.
