What is the use of REST in distributed web application [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 9 years ago.

Improve this question

I am learning about REST API and I am unable to understand how REST is used in distributed web application? This is the only reference i have seen. But still I am unable to learn about REST for distributed computing. Thank You in advance.

Answer 1

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.

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 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 represented objects - although smaller than XML - are still larger than byte-code (this can be solved to a large part by gzip, but creates a second problem)
2. Serialising and Deserialising object to/from strings is very inefficient und much slower than byte-code representations. (And of course zipping the strings to reduce size also costs CPU)

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. Protocol Buffers from Google https://code.google.com/p/protobuf/
2. Apache Thrift http://thrift.apache.org/

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.

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.

Conclusion

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.