I agree. My main goal building an API is to make it easy to consume.
Clients are lazy and impatient, and this is a good thing because it makes the developers work hard to make it easy to connect to their API.
Clients are lazy and impatient, and this is a good thing because it makes the developers work hard to make it easy to connect to their API.
After moving to a REST based API there were endless meetings between co-workers of what is and isn't a good REST url. Our clients often come to us with dumb mistakes. Unlike RPC where the parameters go in a single place. With REST the parameters are spread across the verb, url, header, query param, etc..
With RPC your consumers probably need to know some coding and even maybe a specific language, a framework or a library.
So yes, for me REST is easier, and I always love to see landing pages like this one - https://freegeoip.net - where the client can test the API in a few seconds by copying an example to its browser address line. This is a simple use case, but I hope you get my meaning.
SOAP even has handy discovery tools that frameworks can consume and construct entire APIs in most popular languages.
It's just that no-one uses SOAP from a browser because XML is a royal PITA to write in JS. I would assume it's because all JS developers are too-busy writing more libraries-for and layers-over JSON.