This short note seems to be based on the nowadays common misunderstanding that REST means doing RPC over HTTP with Json payloads. At least, according to the work that coined and defined the term REST -- REpresentational State Transfer --, it described an architectural style or pattern to overcome the inherent limitations of RPC. E.g. have a look at Chapter 6.5.2 of Roy Fielding, "Architectural Styles and the Design of Network-based Software Architectures" [1] to see that why it should not be an RPC mechanism:

  6.5.2 HTTP is not RPC

  People often mistakenly refer to HTTP as a remote procedure call (RPC) [23] mechanism simply 
  because it involves requests and responses. What distinguishes RPC from other forms of 
  network-based application communication is the notion of invoking a procedure on the remote machine,
  wherein the protocol identifies the procedure and passes it a fixed set of parameters, and then waits 
  for the answer to be supplied within a return message using the same interface. Remote method 
  invocation (RMI) is similar, except that the procedure is identified as an {object, method} tuple
  rather than a service procedure. Brokered RMI adds name service indirection and a few other tricks,
  but the interface is basically the same.

  What distinguishes HTTP from RPC isn't the syntax. It isn't even the different characteristics gained
  from using a stream as a parameter, though that helps to explain why existing RPC mechanisms were not
  usable for the Web. What makes HTTP significantly different from RPC is that the requests are directed
  to resources using a generic interface with standard semantics that can be interpreted by intermediaries 
  almost as well as by the machines that originate services. The result is an application that allows
  for layers of transformation and indirection that are independent of the information origin, which is
  very useful for an Internet-scale, multi-organization, anarchically scalable information system. RPC 
  mechanisms, in contrast, are defined in terms of language APIs, not network-based applications.

Nevertheless, many resources on the web use REST to denote a HTTP-based interface which only uses a modicum of the ideas of Representational State Transfer. But the above post goes even further from the original meaning by claiming:

  The thing with REST, is that at its core, it's basically a RPC (Remote Procedure Call) that we've been
  trying to cram in the HTTP protocol.
  

[1]: https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluati...