>Maybe I'm looking at it wrong, and ease-of-use for programmers isn't a goal.
IMO, ease of use for the programmers using the API is not the goal. Ease of maintenance is the goal. Basically RPC is bad because it is an extreme tight coupling between client and server. Change one single parameter in one single SOAP method? Get ready for every single client to have to recompile. Even the ones that never used that particular method (there are techniques to minimize this, but with REST you don't have to think about this problem).
REST is about loose coupling. If you follow HATEOAS properly the clients won't even need to recompile if you do a massive refactoring of where your resources are. So long as you're not doing direct serialization of the XML resources, you also won't have to recompile for every tiny schema tweak. If a field you use changes, obviously you have to change the client. If a field you don't use changes you probably don't even need to restart your client.
This is what it buys you. If you don't get any benefit from the loose coupling then you don't need REST. But if that's the case then I wonder if you need a three tiered system at all.
Forget SOAP. Just think of XML-RPC. How does changing one parameter break things any differently than with REST? If I'm offering an API that has a POST with a body containing a field "client_id", and I change that to "clientid"... stuff breaks.
If you use a single endpoint like "/service" and POST bodies, then there are no "resources" to locate in the first place, so no problem when changing your URI schema. "GET /service?type=account&id=123". Or even just "POST /service {body Action=GetAccount Id=123".
>Maybe I'm looking at it wrong, and ease-of-use for programmers isn't a goal.
IMO, ease of use for the programmers using the API is not the goal. Ease of maintenance is the goal. Basically RPC is bad because it is an extreme tight coupling between client and server. Change one single parameter in one single SOAP method? Get ready for every single client to have to recompile. Even the ones that never used that particular method (there are techniques to minimize this, but with REST you don't have to think about this problem).
REST is about loose coupling. If you follow HATEOAS properly the clients won't even need to recompile if you do a massive refactoring of where your resources are. So long as you're not doing direct serialization of the XML resources, you also won't have to recompile for every tiny schema tweak. If a field you use changes, obviously you have to change the client. If a field you don't use changes you probably don't even need to restart your client.
This is what it buys you. If you don't get any benefit from the loose coupling then you don't need REST. But if that's the case then I wonder if you need a three tiered system at all.