GET / POST RPC is just as easy to debug, IMO, and with less righteous orthodoxy.

The orthodoxy (aka "standard") is there for a reason. It's very easy to shoot yourself in the foot.

If you're only doing small-scale internal interop, especially where you control both ends of all connections, you don't need standards, just do whatever works, but if you have scale dreams, thinking about the rules (What is 'state'? How is it represented? Where?) and why they are there will save you from a lot of headache going forward.

You need a standard within the ecosystem you play in, if only to reduce the amount of work integrating bits and pieces.

For example, I work on an application that has reasonably tight integration between pagination on the front end and parameters / headers on the back end. Works quite well, particularly since we can control both ends. It's not completely ad-hoc - we chose one specific idiom for pagination that had reasonable support, but not necessarily the most widespread - and then extended it slightly when we needed a few operations that had no direct support (e.g. multi-delete, multi-update).

But if you're integrating from everywhere, there's no upside on a unifying standard because any unifying standard will either have so many wrinkles, complexities and caveats to cover every special use case that nobody will implement it correctly or understand it correctly; or it will be ill-suited to many domains, forcing a poor mental model, increasing the probability of bugs and reducing extensibility.

Some http clients can only do GET and POST. If your API demands PUT, PATCH, or DELETE it may be less useful.

How exactly do you think REST is easier to debug and what alternatives are you comparing it to?

Crafting REST request with JSON payload is significantly easier than doing that with SOAP (or, rest it in peace, CORBA).

I don't mind a loose JSON REST-ish API, where everything is a GET, POST or (maybe) a PUT, with explicit endpoints to resolve ambiguities.

Once people start exhibiting excruciating pedantry in designing their APIs, I'll switch off somewhat.

The author was comparing REST to json-rpc. Nowhere in the article does he propose that people use SOA or CORBA.

There's no difference between debugging REST and JSON-RPC over HTTP, so there's no point to compare them. The other alternatives, that I've mentioned, are less easy to debug.

Have you ever seen SoapUI tool[1] ?

It takes just a few clicks to generate complete set of requests from WSDL (set, as in "one request per each operation"). I think it's much better user experience than hand-crafting json to use with curl.

[1] https://www.soapui.org/

That is highly dependent on the language you are using.

Many languages support auto generation of consumer and producer code based off of WSDLs.

And AFAIK, most languages that don't have the auto gen tools do have XPATH libraries for easily manipulating templated SOAP requests.

It's still much faster to run curl with JSON, than to run auto-gen tool and write a whole test program to call an API.

The nice thing about SOAP was it had a full-fledged type system built in. REST is certainly easier to debug, but it's also more likely you'll be required to debug it, since many of the problems you'll run into in a REST interface would have been caught at compile time with SOAP.

SOAP's big problem, IMO, was the crazy insistence on URI formatted namespaces, which took a simple XML message and turned it into something bloated and confusing.

And caching is easy to implement independently of the API using a proxy