As software architects, we often debate using REST versus gRPC for designing service communication APIs. While both power countless cloud applications today, they take fundamentally different approaches.

Let's dive into the strengths of each to help determine the best fit for API requirements now and in the future.

Data Transport: JSON vs Protocol Buffers

REST uses lighter-weight JSON over HTTP while gRPC transmits Protocol Buffers payloads:

// REST POST JSON 

HttpEntity<Person> request = new HttpEntity<>(new Person("Jane"));
restTemplate.postForObject("/people", request, Person.class);


// gRPC Unary Call with Protobuf

stub.createPerson(Person.newBuilder().setName("Jane").build());

JSON is human-readable but less efficient. Protobufs are dense and high-performance but not intended to be authored manually.

Winner: Tie. Choose JSON for simpler debugging and Protobuf where bandwidth and compute matter.

Contract: Open vs Strict Schema

REST endpoints expose open-ended JSON contracts. gRPC enforces strict interface definitions specified in .proto files:

// Sample gRPC .proto

service PeopleService {
   rpc CreatePerson(Person) returns (PersonId) {}   
}

message Person {
  string name = 1; 
}

This provides gRPC bonuses like compile-time checking and client code generation but reduces API flexibility.

Winner: REST for public-facing APIs and gRPC for internal microservices where stability matters.

Security: Bearer Tokens vs TLS

REST usually authenticates via bearer tokens in request headers:

Authorization: Bearer <JWT_TOKEN>

gRPC uses transport-layer security for encryption and auth:

// gRPC channel with TLS 

ManagedChannel channel = NettyChannelBuilder.forAddress(host, port)
    .sslContext(sslContext)
    .build();

TLS incurs extra setup but enables secure communication without custom token logic on every request.

Winner: gRPC with TLS for internal infrastructure. Use REST + OAuth for public APIs.

Networking: HTTP/1.1 vs HTTP/2 Multiplexing

REST traditionally leverages text-based HTTP/1.1 request-response flows. gRPC builds on HTTP/2 enabling optimized binary streams:

HTTP/1.1:
GET /api/people  
{id: 123, name: "Jane"}

HTTP/2: 
[Binary proto Person payload]

This allows gRPC to multiplex bidirectional streams over a single TCP connection for better throughput.

Winner: gRPC for performance at scale. Adopt HTTP/2 for REST if latency matters.

Functionality: Resources vs RPCs

REST operates on named resource endpoints using standard verbs like GET, POST, PUT. gRPC exposes behaviors as remote procedure calls:

// REST
GET /people/123 

// gRPC 
service PeopleService {
  rpc GetPerson(PersonId) returns (Person) {}
}

RPC semantics better model app capabilities but obstruct caching, proxies and splits.

Winner: Personal preference. REST encourages web scale. RPCs match app semantics.

Conclusion

gRPC delivers high-performance networked RPCs with static typing. REST enables public HTTP services with JSON flexibility.

Evaluate service requirements, client needs, and team experience to determine the optimal approach rather than declaring one universally "better". Mix and match as needed - many architectures employ both REST and gRPC today!