我不太清楚，您在问什么问题，但通常-REST只是执行RMI（远程方法调用）或RPC（远程过程调用）的另一种方法。但是，尽管RMI仅在Java中起作用，但是REST使用HTTP协议进行通信。由于HTTP是我们当今使用的大多数技术/库/语言中实现的，因此这是连接它们的简便方法。

It isn’t really clear to me, what you are asking with your question, but generally - REST is just another way to do RMI (Remote Method Invocation) or RPC (Remote Procedure Call). However, while RMI works only within Java, REST uses the HTTP Protocol to for communication. Since HTTP is implemented in most of the technologies / libraries / languages we use today, it is an easy way to connect them.

最初是SOAP（简单对象访问协议）用于实现服务器之间和客户端与服务器之间的通信。 SOAP除了HTTP之外还具有许多其他功能。 WSDL（例如 Web服务描述语言）允许自动生成代理。虽然这些功能使SOAP丰富且非常适合企业应用程序（CERN实施了自己的SOAP版本，允许状态完全通信），但对于许多快速变化的小型公司来说，它也太庞大了。

Originally SOAP (Simple Object Access Protocol) was used to implement inter server and client-server communications. SOAP has many additional features on top of HTTP. The WSDL (Web Services Description Language) allows for automatic proxy generation, for instance. While those features make SOAP rich and perfect fit for Enterprise applications (CERN implemented their own version of SOAP which allowed state-full communication), it was also too bulky for many, quickly changing, smaller companies.

REST使用来自HTTP的功能，但基本上可以在许多方面有所不同。可以***定义url和对象，以及对象序列化的格式（主要是JSON）。此功能与Python，Ruby或JavaScript（客户端或NodeJS）等动态语言配合使用，可以非常轻松地在不同服务之间以及客户端和服务之间建立通信（SPA-单页应用程序，稍后介绍）。

REST uses features from HTTP but can basically vary in many ways. The url's and the objects can be defined freely, as well as the format in which objects are serialised (mostly JSON). This feature paired with dynamic languages like Python, Ruby or JavaScript (Client, or NodeJS) makes it very easy to set up communication between different services as well as client and service (SPA - Single Page Application, for the later).

但是，我认为一个非常有趣的事实是，人们发现，您必须为此付出高昂的代价：

However, I think the very interesting fact is, that people discovered, you have to pay a high price for this elasticity:

1. JSON表示的对象虽然比XML小，但仍大于字节码（这可以通过gzip解决，但会带来第二个问题）


2. 对象到字符串的串行化和反序列化非常低效，并且比字节码表示慢得多。 （当然，压缩字符串以减小大小也会消耗CPU资源）

到目前为止，我们可以选择-HTTP效率低下，或RMI，它不灵活，只能由几种语言使用。这就是为什么有两个项目可以解决这个问题的原因：

So far there was the choice - HTTP, which is inefficient, or RMI, which is inflexible and can be used only by few languages. This is why there are two projects to solve this:

1. Google https://code.google.com/p/protobuf/


2. Apache Thrift http://thrift.apache.org/

1. Protocol Buffers from Google https://code.google.com/p/protobuf/
2. Apache Thrift http://thrift.apache.org/

这两个项目都允许您使用特定的二进制格式来发送消息。而且，由于两个项目都使用不同的语言实现（Apache Thrift比Google的Protocol Buffer要多得多），因此您可以使用这种格式在不同的服务器之间进行通信。

Both of those projects allow you to use a specific binary format, to you and your messages. And because both projects have implementations in different languages (Apache Thrift many more than Google's Protocol Buffer) you can use this format to communicate between different servers.

端到端通信并不总是您想要的，这就是为什么存在不同的消息传递队列，这些消息传递队列除了可以进行消息转发外还可以完成许多任务（例如，发布-订阅，循环传递给一组服务等）。可能最广泛使用的是 ZeroMQ 。

Also a direct end-to-end communication is not always what you want, which is, why there are different Messaging Queues which can fulfil many tasks additionally to message forwarding (for instance publish-subscribe, round robin delivery to a set of services, ...) The probably most widely used one is ZeroMQ.

您可以使用REST在分布式Web应用程序中的不同服务之间进行通信。而且由于在许多不同的主机和技术之间实现这种通信通道的简单性，这种方法也经常使用。但是，序列化/反序列化的开销可能会花费您大量的CPU时间，尤其是当您拥有具有许多服务的大型后端基础结构时。这就是为什么您应该选择一种二​​进制格式（Apache Thrift，协议缓冲区）以确保效率的原因。

You can use REST to communicate between different services in your distributed web applications. And this is also often used, due to the simplicity of implementing such a communication channel between many different hosts and technologies. However the overhead in serialising / deserialising can cost you a lot of CPU-Time, especially if you have a large backend infrastructure with many services. This is why you should rather choose one of the binary formats (Apache Thrift, Protocol Buffers), to ensure efficiency.