The proliferation of microservices has led to many new innovative approaches in the software world. However, building robust, quality APIs that consistently deliver the business outcomes you desire can be a complex task. It’s no wonder a recent survey of organizations adopting microservices found that nearly 30% of the respondents listed “API quality” as one of their biggest challenges.
API-based applications don’t just come in one flavor. Each API format has a unique set of advantages and disadvantages, and choosing which to use depends heavily on your specific application requirements.
In this two-part blog series, we’ll explore the three most popular approaches to API development: REST, gRPC and GraphQL. We’ll take a look at the benefits and drawbacks of each model and discuss how you can determine which API model best suits your needs.
REpresentational State Transfer (REST) is the most popular API architecture in use today. Focused on representing application state through web resources, REST uses HTTP verbs, each of which serves a narrow purpose:
- POST: create a new resource.
- PUT: update a resource entirely if it exists or create it if it does not.
- DELETE: delete a resource.
- PATCH: update an existing resource partially.
- GET: query for an existing resource or resources.
Benefits and drawbacks of REST
Because RESTful APIs are so widely used, most application developers are familiar with them. Because REST aligns closely with the design of the HTTP protocol, browsers and other HTTP clients will natively understand responses from your RESTful APIs.
REST isn’t a cure-all though, which is why it’s not the only API architecture out there. RESTful APIs can result in bloated responses, especially if resources are particularly complex, which is one of the drivers behind the growing popularity of GraphQL. REST also may not be an ideal choice for very low-powered clients, which is what makes gRPC attractive in this case.
The flexibility of RESTful API development also puts the onus of adhering to principles and standards on the developer. While the OpenAPI Specification is a great tool for this, sticking to it must be an active decision, since RESTful APIs are not inherently self-documenting.
When to use REST
If you don’t have a compelling reason to choose otherwise, REST is probably the best option for your application. While GraphQL or gRPC might fit use cases with unique needs, it’s more often the case that you just want to build with a good, solid API approach. For its shallow learning curve, a massive ecosystem of resources and a wealth of publicly available examples to learn from, you should consider REST APIs as your default choice.
gRPC was designed and developed by Google, so it is sometimes referred to as Google Remote Procedure Calls.
gRPC is an evolved design of the more generic concept of remote procedure calls. It allows a client to call a method on a remote computer directly as if that system was local. gRPC makes use of protocol buffers (or Protobufs) to define a typesafe interface with data serialized into binary—rather than text-based JSON or XML—for data transfer. It also makes use of the speed and efficiency of HTTP/2 which is more reliable and faster than HTTP/1.
gRPC APIs have four different service methods:
- Unary: The client makes a single request to the server, and the server returns a single response.
- Client-Streaming: The client streams a series of requests to the server, followed by a message to indicate the stream is finished. Then, the server returns a single response.
- Server-Streaming: After the client sends a single request, the server responds by streaming a series of messages. The stream continues until all messages are sent or the client disconnects.
- Bidirectional Streaming: An initial connection is established between client and server, and either can send messages as needed, or either can terminate the connection.
Benefits and drawbacks of gRPC
Using Protobufs for data serialization, gRPC provides an incredibly lightweight and fast API. Because it is so lightweight, gRPC is often used when the client may not have much computing power (such as IoT). In these cases, the server does the heavy lifting.
gRPC also provides an excellent way to communicate between services written in different languages, given the language-agnostic definition of the interface contract. This makes the learning curve for gRPC—though not quite as shallow as REST—quite tolerable.
While gRPC is highly efficient, it isn’t well supported by browsers. It can also be difficult to learn by experimenting in a sandbox. The usage of HTTP/2 is also likely to be unfamiliar to less experienced API developers.
When to use gRPC
If you need to squeeze every drop of performance out of your client machines, gRPC can be a great choice. This is why a widespread use case for gRPC is to facilitate communication among smart devices. Given their size, limited computing resources and real-time functionalities, IoT devices depend on the performance of gRPC to function. Deployment pipeline tooling and application monitoring systems can also be great applications for gRPC.
In part one of this blog, we examined REST and gRPC under the microscope to better understand their key differentiators in the API development landscape. In part two of this series, we’ll cover GraphQL and explore its own unique set of differentiators. Finally, we’ll recap our findings with a side-by-side comparison of the three API models and how they may support your team’s current use case.