Is RPC better, or RESTful better?

I saw such a question on
Zhihu. In WEB development, is it better to use JSON-RPC or RESTful API?
Are there any other good recommendations?
-------------------------------------------------- ---------------
First , what is the
difference between REST and RESTful?
REST, the abbreviation of Representational State Transfer. The translation is the state transition of the presentation layer.
If an architecture conforms to REST principles, it is called a RESTful architecture.
What is json-rpc?
An interface call usually consists of two parts, serialization and communication protocol. Common serialization protocols include json, xml, hession, protobuf, thrift, text, bytes, etc. The popular ones for communication are http, soap, websockect, RPC is usually implemented based on TCP, and common frameworks such as netty.
RESTful is usually implemented using http+JSON.
JSON-RPC means that the communication protocol adopts binary mode instead of http, and serialization adopts the form of JSON.
The most liked answer
Weng Wei 262 people agree that
JSON-RPC is much better than RESTful API.
======
I hate restful APIs as much as I hate OOP; but rather than I hate restful, I hate some pseudo-programmers who advocate restful APIs.
Many programmers who advocate restful API actually do not understand the design concept of restful.
As a qualified technician, the most basic requirement is to have an understanding of the technologies you use, understand the applicable scenarios of various technologies, and then adapt to local conditions.
Restful first requires that all applications must be defined as "resources", and then only four limited operations can be performed on resources.
This is a very bad abstraction of the API. There are too many APIs that are actually needed and cannot be smoothly integrated into the specifications defined by restful.
For example, user login / resetpassword and so on.
Believers of restful, they will say that according to this and that specification, login / password, etc. can also be included as some kind of resources, and then add, delete, modify and check. In my opinion, this is purely to solve some problems that did not exist and need not be solved at all, and it is pure waste.
For all interfaces, there are corresponding functions on the server side, and they have their own namespaces, accepted parameters, return values, exceptions, and so on.
It can be exposed in a light way.
There is no need to re-categorize a bunch of functions into "resources", and then cut the head and map all operations to "add, delete, modify and check".
Corresponding to the web, there are many mature solutions for rpc, including ancient soap and lightweight json rpc.
JSON rpc basically only requires that all requests must have msg id, function name, parameters can be defined, and return value and exception can be distinguished; "namespace" can also be defined to divide function modules.
This is consistent with module and function definitions in most languages, and is very convenient to use.
Many JSON RPCs are used for web front-end Ajax calls. If the front-end calls are properly abstracted, calling remote APIs is actually no different from calling local functions.
实际上，json rpc也未必需要跟http绑定，即便是在web上，它也可以走web socket，这样子，前端可以使用同一web socket管道批量发送请求，而服务器端乱序返回结果时，前端也可以根据msg id做准确的回调。
websocket，批量调用，乱序返回，这些都可以显著提高API的输出吞吐，这些是在json rpc的设计考量内。
调用更方便，性能也更好，两全其美是完全可能的。
想当然的为了“快”，为了“简单”就必须牺牲别的，这是严重的思维误区。
有些方案，纯粹就是糟糕的方案。
restful API仅适用与业务非常简单的场景，比方说，就是为了提供少量数据表单的增删改查。而这种场景实在是太过简单，实际中几乎找不到。
----------------------------------------------------------
我的观点
实际上，这个问题本质上是RESTful和RPC之争。这两种风格都是随着架构发展而来。分别适用不同的场景。
http vs 高性能二进制协议
http相对更规范，更标准，更通用，无论哪种语言都支持http协议。如果你是对外开放API，例如开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的支持，相应的，如果采用http，无疑在你实现SDK之前，支持了所有语言，所以，现在开源中间件，基本最先支持的几个协议都包含RESTful。
RPC协议性能要高的多，例如Protobuf、Thrift、Kyro等，（如果算上序列化）吞吐量大概能达到http的二倍。响应时间也更为出色。千万不要小看这点性能损耗，公认的，微服务做的比较好的，例如，netflix、阿里，曾经都传出过为了提升性能而合并服务。如果是交付型的项目，性能更为重要，因为你卖给客户往往靠的就是性能上微弱的优势。
RESTful的规范到底是不是鸡肋？
我认为，微服务的盛行，开放平台的盛行，的确让RESTful过于“流行”了。你可以看看，无论是Google、Amazon、netflix（据说很可能转向grpc），还是阿里，实际上内部都是采用性能更高的RPC方式。而对外开放的才是RESTful。
如果你的应用非常简单，无论用哪种都无所谓了，基本都能满足要求。
关于无状态、幂等
这个跟你是否采用RESTful无关，主要还是看接口内部实现，所以，把这个作为RESTful优点的可以闭嘴了。
安全性
显然，基于Http更安全一些，默认80端口，防火墙友好。
RESTful也分为严格的和自由的
RESTful还有个好处是制定了一系列规范，但是大多数使用者都是自由风格的，根本不是严格按照RESTful规范实现。当然存在就是道理，这样做更高效，但是不够通用。
无疑，严格按照资源抽象，API看起来更清晰，更容易被大家理解。同时，开发人员的复杂度也更高。
最后建议
对外开放给全世界的API推荐采用RESTful，是否严格按照规范是一个要权衡的问题。要综合成本、稳定性、易用性、业务场景等等多种因素。
内部调用推荐采用RPC方式。当然不能一概而论，还要看具体的业务场景。
另外一个因素是人，关键是你有什么人，postgresql、MySQL is useful and good, move from place to place, the key is which one your people are more familiar with.