REST API has long been the standard, but it has its limitations. When load increases, streaming scenarios appear, or business requires faster communication between services, REST stops being the ultimate solution. gRPC solves what REST cannot: it provides high data transfer speeds, supports streaming, and enforces a strict interaction structure. It is convenient to use in microservices, mobile, and IoT applications.
For a tester, this means one thing: knowing how to work with gRPC is shifting from a "nice-to-have" to an essential skill. If you haven't worked with this protocol yet, this article will help you understand its basics, how it differs from REST, the structure of .proto files, and most importantly - how to test gRPC services using Postman.
What is gRPC and Why is it Needed?
gRPC is a high-performance framework from Google. As a QA specialist, you don't necessarily need to dive into implementation details, but understanding how this protocol works and how to test it will definitely be useful.
To simplify, REST can be compared to paper letters sent in envelopes, while gRPC is like a phone call. Both are formats for communication between an application and a server, but with REST API, data is transferred in JSON or XML formats, which in our analogy can be equated to envelopes. This is okay and works, but not always fast or convenient.
gRPC proposes wrapping data in a binary protocol, which transmits data faster, has a smaller size, and is strictly structured. It uses Protocol Buffers (protobuf). Thanks to this, both sides participating in the information exchange know in advance what questions will be asked and what answers to expect. For a tester, this means less ambiguity and more predictability in verifications.
When we first implemented gRPC in a project, it unexpectedly turned out that Postman, by default, couldn't work with this protocol. We had to find workarounds - we tried BloomRPC, then grpcurl. In the end, we found a solution: uploading .proto files into a new beta version of Postman. It was a useful lesson - tools aren't always ready "out of the box," and it's important for a tester to have several alternatives on hand.
Key Advantages of gRPC
Why is gRPC usage increasingly common in product development? Here are the main reasons:
- High performance thanks to the binary protobuf format.
- Support for streaming: data can be transmitted not only in a "request-response" format but also as streams.
- Cross-platform: gRPC can be used for projects in different programming languages.
- Code autogeneration: client and server code is automatically generated from .proto files.
All of this leads to fewer misunderstandings with developers, clear rules for validation, and new testing scenarios - for example, for streaming.
Key Differences Between gRPC and REST
Moving from testing REST to gRPC implies conceptual changes in the process. Instead of endpoints and HTTP methods - methods and messages described in a contract. For convenience, let's compare them in a table.
Next, let's look in more detail at one of gRPC's advantages over REST - the presence of streaming.
Types of gRPC Calls
Unlike REST, which has the familiar GET/POST/PUT/DELETE, gRPC works with methods defined in a .proto file.
Four types of calls are supported:
- Unary - one request, one response.
- Server streaming - one request, stream of responses.
- Client streaming - stream of requests, one response.
- Bidirectional streaming - stream of requests, stream of responses.
When designing tests, it's important to consider that "one test - one request" isn't always suitable. For streaming, you need scenarios with multiple sequential messages.
But to understand which methods are available and what data can be transmitted in these calls, you need to understand how a .proto file is structured.
How a .proto File is Structured
This is a simple text file with a .proto extension. In it, we essentially agree on what data can be sent and received, and what methods the service has.
You can think of it as an instruction or contract between the service developer and those who use it (for example, QA specialists).
Usually, the .proto file is created by the backend service developer, because they know which methods the service must support, as well as what data is accepted and returned.
A tester can also open a .proto file to understand how to correctly form a request, suggest improvements (for example, add a field or change a data type), and, if desired, write their own .proto for learning or experiments.
Before moving on to the structure of a .proto file, let's make an important clarification.
gRPC indeed transmits data in the binary Protocol Buffers format, not JSON - this is why it is more efficient than REST in terms of speed and traffic volume. However, when testing via tools like Postman, BloomRPC, or grpcurl, you will see requests and responses in a human-readable format resembling JSON. This is a visualization of the binary data for humans. The tools automatically convert the binary stream into such "pseudo-JSON" to make it easier for you to work with the fields.
In our examples, we will also use this readable format - not because gRPC uses JSON, but so you can quickly understand the message structure.
Let's look at a simple example of a .proto file:
syntax = "proto3";
service HelloService {
rpc SayHello (HelloRequest) returns (HelloResponse);
}
message HelloRequest {
string name = 1;
}
message HelloResponse {
string message = 1;
}
What's Inside:
Syntax Specification
syntax = "proto3";
Syntax indicates which version of the Protocol Buffers language we are using.
At the time of writing, the current version is the third - proto3.
Service Definition
service HelloService {
rpc SayHello (HelloRequest) returns (HelloResponse);
}
service HelloService - declaration of a service named HelloService.
You can think of a service as a class containing methods.
rpc SayHello (...) returns (...)- this describes a remote procedure call, where:
- SayHello — the method name.
- (HelloRequest) — what the method accepts (request type).
- returns (HelloResponse) — what the method returns (response type).
In our example, the service has only one method, SayHello, which accepts a HelloRequest message and returns a HelloResponse.
Request Message Description
message HelloRequest {
string name = 1;
}
Message HelloRequest defines the data type for the request. Inside it:
string name = 1;
- string - data type (string).
- name - field name.
- = 1 - sequence number (needed for serialisation).
This means: the client must pass a string field name.
Example:
Response Message Description
message HelloResponse {
string message = 1;
}
Message HelloResponse defines the data type for the response. Inside:
string message = 1;
- a string that will contain the result.
In our case, the server will return a greeting string.
Example:
All of this works as follows: the client calls the SayHello method, in the HelloRequest it sends the name field, the server receives this field, forms a response, and in the HelloResponse it returns a string with a greeting.
If you know how to read and understand .proto files, you can easily grasp the data structure and suggest improvements to the API even at the design stage.
And now, it's logical to move on to the next question: what else does the service return besides useful data? Here we'll talk about gRPC status codes.
gRPC Status Codes: What a Tester Needs to Know
In gRPC, every response (even a successful one) is accompanied by a status code. These are not HTTP 200/404/500, but their own set of codes defined in the gRPC library. In total, gRPC has 17 predefined status codes, from 0 to 16, but we will consider only the most basic and commonly used ones.
Main gRPC Status Codes
It's important not only to verify the correctness of the data in the response but also to ensure the service correctly returns status codes in various scenarios.
gRPC in Postman: Practical Testing
Previously, Postman could only work with REST, but now - also with gRPC.
How it works:
- Upload the .proto file into Postman.
- Select the service and method.
- Form the request (data is taken from the request structure in the .proto).
- Look at the response and status code.
For example, for a simple service:
A request in Postman will contain the name field, and in response a greeting message will arrive.
Let's look at an example.
- Create a new request → select the request type gRPC Request (not HTTP!).
- Specify the URL, open the Service Definition tab, import the .proto file.
- After importing the .proto file, all available methods the service can work with will become available for selection.
- Select the method we need, and a JSON-like form with fields that need to be filled in will appear in the request body (all required fields are defined in our .proto file).
- Click Invoke and you will see the response and status code.
Summary
- gRPC is faster than REST, supports streaming, and enforces strict contracts.
- For a tester, the key skills are: being able to read .proto files, check different call types, and work with tools (Postman, grpcurl, BloomRPC).
- Don't forget about status codes: they help understand how a service behaves in error scenarios.
- In practice, you may encounter pitfalls: not every tool supports gRPC as conveniently as REST.
By mastering gRPC, you will expand your arsenal: you'll be able to test not only REST services but also more modern microservice systems. And that means - you'll become a more in-demand specialist.
Author: Vasil Khamidullin
Top comments (0)