When building a new web-based service, one of the inevitable questions that comes up is “How am I going to talk to it?” Do you use REST? gRPC? …or maybe SOAP? In this post, myself and Ovi take a look at at both (and a quick glance at SOAP) to see if one is better than the other…
When we started designing our BuildVu Microservice Example, we did a fair bit of research into both REST and gRPC before deciding to go with REST. Each has it’s pros and cons, but rather than “one true solution to rule them all”, both were pretty evenly matched. REST is simple, straightforward and has widespread usage & support, while gRPC has better performance under load and has some nice features that cut out some of the annoying parts of REST (looking at you, headers).
Before we dive into comparing the 2, there’s one more question:
“Are we comparing apples to oranges?”. gRPC is a framework, yet REST is an architecture / design concept, so is it really fair?
Well, yes – although they’re not exactly the same, they’re both still tools used for communication between web services that perform the same task / fulfill the same goal. So, without further ado, let’s kick things off with REST…
REST:
REST (REpresentational State Transfer) is a design concept or architectural pattern, with a resource-oriented focus – software solutions are modelled as collections of resources that the user can access and interact with, using a consistent interface.
REST puts simplicity first. It is lightweight and often (when implemented properly) has simple, easy to understand URLs. For example, if you sent a GET request to ‘…example.com/users/10’, you would assume it will return data related to the user with the ID 10. If you sent a DELETE request to the same URL, it would delete that data. The focus of REST is on what is communicated between services, not how. Rather than reinventing the wheel, HTTP verbs (such as GET, POST, etc.) are used for requests and HTTP status codes are also used to describe request status. However, you do have to deal with headers – which can be a little annoying at times.
One of the great things about REST is that it’s stateless. This means that no client context is stored on the server between requests – each request from any client contains all the information necessary to service it, and session state is held in the client (although it’s worth noting there’s nothing stopping you storing session data if you want to!). This is good for serverless solutions – no need to spend extra on storage / memory compared to a service that stores session states server-side.
REST is also highly flexible. It supports multiple content types, be it JSON, CSV, XML, RSS, raw binary… pick your poison. Furthermore, like gRPC, REST doesn’t care what programming language you’re using either – as long as the web service receives the aforementioned data in a format it’s expecting, everything is OK.
On the other hand, although REST (like gRPC) is highly scalable, gRPC performs better under high loads. It’s a matter of milliseconds rather than seconds, but for services that are dealing with hundreds of thousands or millions of requests it all adds up!
Finally, despite its downsides, you can’t deny that REST has much more browser & language support than gRPC – it’s almost everywhere you go online. Any programming language that supports sending and receiving HTTP requests and JSON / XML is able to interact with a RESTful web service.
gRPC:
gRPC is a framework originally created by Google. GRPC.io claims the name stands for gRPC Remote Procedure Calls, presumably to distance itself from the Google origins now that it is open-source.
While REST is built on a resource-based ideology, gRPC aims to make use of HTTP/2.0 which allows for bi-directional communication. As mentioned earlier, REST provides cross-language support as all requests are handled via data-interchange formats like XML and JSON — but why would you use XML these days ????? In contrast, gRPC communicates using binary data via Protocol Buffers for serializing structured data. As a result, language support for gRPC depends on language adoption of proto3 (the latest version of Protocol Buffer) which currently supports Java, C#, C++, Python, Ruby, JavaScript and Objective-C. Protocol Buffers are similar to XML in that they are verbose but the serialization of transferred data offers a large performance boost compared to that of JSON or XML via REST.
When dealing with REST, you will be encountering the need to specify methods, headers, body etc. gRPC abstracts all this via the grpc-web-client. Additionally when using REST, HTTP errors can become unclear or simply incorrectly used — gRPC provides well-defined status codes to identify exactly what issue has occurred.
One philosophy behind gRPC is to make it feel like you are using a service on the same machine. To achieve this gRPC requires 2 parties to be set up, the server as usual as well as the client. “.proto” format API contracts are used to provide a common interface of communication between the two parties. This prevents the client from needing to hunt down API documentation as it is already specified locally. Along with the ability to use .proto to agree on data structures, the contracts can also define types and prevent client requests from being sent altogether when types do not match.
Given all these seemingly positive features of gRPC, there are still a couple of elephants in the room. For one, gRPC is not widely adopted — not widely at all for that matter. REST runs the web when it comes to popularity. As a result the standard is set and moving away from it can be a daunting task. This applies to companies considering the change as well as developers not being overly keen on learning a new standard when it is rarely seen on job listings. REST is arguably simpler to set up and not every web service requires speed improvements by the millisecond. Arguably, the best use for gRPC right now is the development of new microservices where speed and scalability are of top priority.
Honorable mention: SOAP
Simple Object Access Protocol, more commonly known as SOAP, is a messaging protocol specification developed by Microsoft for exchanging structured information between web services. While REST is all about resources, SOAP exposes components of application logic as services rather than data.
Compared to REST, benefits of SOAP include built-in retry logic (for better handling of failed communications) and that it’s highly extensible through other protocols and technologies… and that’s about it. The general rule I’ve been told is ‘Unless you have a definitive reason to use SOAP use REST’!
So… which do I pick?
At the end on the day – as I mentioned at the beginning of this post – which framework you pick depends on what you’re trying to do. gRPC is a solid choice if you don’t mind a little extra effort for the performance and other benefits, or want to try something new (something you unfortunately don’t often see in industry!). On the other hand, if you want to keep it simple and get set up quickly, you may want to go with REST.
Do you have any preference when it comes to REST or gRPC? Maybe you use something else – let us know in the comments below.