0Pricing
PHP Academy · Lección

Comunicación entre servicios: REST y gRPC

Conecte servicios de forma síncrona y eficiente

Comunicación entre servicios: REST y gRPC es una lección gratuita de PHP Academy en CoddyKit. Esta es la lección 2 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de PHP Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de PHP Academy incluye 4 lecciones en total.

REST y gRPC

Los servicios necesitan comunicarse de forma síncrona: se envía una solicitud y vuelve una respuesta. Las dos opciones predominantes son REST sobre HTTP/JSON y gRPC sobre HTTP/2 + Protobuf. Cada una optimiza aspectos diferentes: REST busca alcance y facilidad de uso, mientras que gRPC busca velocidad y contratos estrictos.

Esta lección muestra ambas opciones desde la perspectiva de PHP y explica cuándo elegir cada una.

REST: la lengua franca

REST modela recursos mediante URL y utiliza verbos HTTP y códigos de estado para expresar la semántica. Sus ventajas son las herramientas universales, la capacidad de caché, la facilidad de depuración con curl y el hecho de no requerir clientes especiales. Sus desventajas son el JSON verboso, la ausencia de un esquema obligatorio y el hecho de limitarse a solicitudes y respuestas.

Para las API públicas y los endpoints orientados al navegador, REST casi siempre es la opción adecuada.

Llamar a un servicio REST

Utilice un cliente HTTP PSR-18 (Guzzle en este caso). Establezca siempre un tiempo de espera de conexión y de solicitud; una llamada sin límite a un servicio lento puede agotar sus workers de PHP-FPM y provocar una interrupción en cascada.

<?php
require 'vendor/autoload.php';
use GuzzleHttp\Client;

$http = new Client([
    'base_uri'        => 'http://customers-svc/',
    'connect_timeout' => 1.0,  // never block forever on connect
    'timeout'         => 3.0,  // total request budget
    'http_errors'     => false,
]);

$res = $http->get('customers/42', ['headers' => ['Accept' => 'application/json']]);
if ($res->getStatusCode() === 200) {
    $customer = json_decode((string) $res->getBody(), true);
    echo $customer['email'] . "\n";
}

Los códigos de estado son el contrato

En REST entre servicios, los códigos de estado HTTP son su protocolo de errores. Trátelos de forma deliberada:

  • 2xx indica éxito; 4xx, un error del cliente (no los reintente a ciegas); 5xx y los tiempos de espera agotados se pueden reintentar.
  • Use 409 para conflictos, 422 para errores de validación y 429 para límites de frecuencia (respete Retry-After).

Reintentar un 400 solo desperdicia llamadas; reintentar un 503 con backoff es correcto.

<?php
function isRetryable(int $status): bool {
    return $status === 0          // timeout/connection error
        || $status === 429
        || ($status >= 500 && $status !== 501);
}
var_dump(isRetryable(503)); // true
var_dump(isRetryable(400)); // false

gRPC: contrato primero y alta velocidad

gRPC utiliza Protocol Buffers: se definen servicios y mensajes en un archivo .proto y después se generan stubs de cliente y servidor fuertemente tipados. Sobre HTTP/2, con Protobuf binario, es mucho más compacto y tiene menor latencia que JSON, además de admitir streaming.

syntax = "proto3";
package customers;

service Customers {
  rpc GetCustomer (GetCustomerRequest) returns (Customer);
}

message GetCustomerRequest { string id = 1; }
message Customer {
  string id = 1;
  string email = 2;
  int32  loyalty_points = 3;
}

Generar stubs de PHP

Instale la extensión gRPC de PHP y el plugin de protoc; después genere las clases cliente a partir del archivo .proto. PHP puede actuar como un cliente gRPC completamente funcional mediante ext-grpc; para ejecutar un servidor gRPC nativo en PHP normalmente se necesita Roadrunner o Swoole.

pecl install grpc
composer require grpc/grpc google/protobuf

protoc --proto_path=. \
  --php_out=./generated \
  --grpc_out=./generated \
  --plugin=protoc-gen-grpc=$(which grpc_php_plugin) \
  customers.proto

Una llamada de cliente gRPC

Los stubs generados proporcionan solicitudes y respuestas tipadas. Una llamada gRPC devuelve el mensaje y un objeto status; compruebe siempre el código de estado antes de confiar en la respuesta.

<?php
require 'vendor/autoload.php';
use Customers\CustomersClient;
use Customers\GetCustomerRequest;
use Grpc\ChannelCredentials;

$client = new CustomersClient('customers-svc:50051', [
    'credentials' => ChannelCredentials::createInsecure(),
]);

$req = (new GetCustomerRequest())->setId('42');
[$reply, $status] = $client->GetCustomer($req)->wait();

if ($status->code === \Grpc\STATUS_OK) {
    echo $reply->getEmail(), "\n";
} else {
    fwrite(STDERR, "gRPC error: {$status->details}\n");
}

Evolución del esquema

Protobuf está diseñado para ofrecer compatibilidad hacia delante y hacia atrás, siempre que respete sus reglas:

  • Nunca reutilice ni cambie un número de campo. Añada los campos nuevos con números nuevos.
  • Marque los campos eliminados como reserved para impedir que se recicle el número.
  • Los clientes antiguos ignoran los campos desconocidos; los campos ausentes toman los valores predeterminados de su tipo.

JSON/REST no ofrece nada de esto de forma gratuita; debe garantizar la compatibilidad por convención (e, idealmente, mediante un esquema OpenAPI compartido con pruebas de contrato).

message Customer {
  string id = 1;
  string email = 2;
  reserved 3;            // old 'loyalty_points', never reuse 3
  reserved "loyalty_points";
  string display_name = 4; // new field, safe additive change
}

Streaming

gRPC admite cuatro tipos de llamada; REST admite de forma nativa únicamente el primero:

  • Unaria: una solicitud y una respuesta.
  • Streaming del servidor: una solicitud y un flujo de respuestas (por ejemplo, actualizaciones en directo).
  • Streaming del cliente: un flujo de solicitudes y una respuesta (por ejemplo, una carga masiva).
  • Bidireccional: ambos flujos funcionan simultáneamente.

Si su caso de uso requiere push o un flujo de datos de larga duración, el streaming de gRPC es mejor que consultar repetidamente un endpoint REST.

Propagación del contexto y los deadlines

Las llamadas síncronas forman cadenas, por lo que dos elementos deben viajar con cada solicitud: un id de correlación/traza para la trazabilidad integral y un deadline para impedir que un servicio lento al final de la cadena haga que toda la cadena se bloquee. gRPC ofrece deadlines de primera clase; en REST se emulan con un presupuesto de tiempo de espera decreciente que se transmite aguas abajo.

<?php
// REST: shrink the remaining budget as the call chain deepens
function forwardHeaders(array $incoming, float $remainingMs): array {
    return [
        'X-Correlation-Id' => $incoming['X-Correlation-Id'] ?? bin2hex(random_bytes(8)),
        // downstream must finish within what's left of our budget
        'X-Timeout-Ms'     => (string) max(0, (int) $remainingMs),
    ];
}
print_r(forwardHeaders(['X-Correlation-Id' => 'trace-9'], 1500));

Elegir entre ambos

Una guía práctica para decidir:

  • REST para API públicas o de socios, clientes de navegador, CRUD sencillo, depuración fácil y amplio soporte de caché.
  • gRPC para llamadas internas entre servicios con mucho volumen y baja latencia, contratos tipados estrictos y streaming.

Muchos sistemas utilizan ambos: gRPC detrás de la gateway, entre servicios, y REST en el perímetro para el mundo exterior. No obligue a una herramienta a hacer el trabajo de la otra.

Comprobación rápida

Elegir el protocolo según el caso de uso.

Resumen

Comunicación síncrona entre servicios:

  • REST/JSON: universal, fácil de depurar y compatible con caché; los códigos de estado son el contrato; establezca siempre tiempos de espera.
  • gRPC/Protobuf: contrato primero, compacto, rápido y compatible con streaming; genere stubs de PHP tipados.
  • Decida si se pueden hacer reintentos según los códigos de estado o de gRPC; nunca reintente errores del cliente.
  • Haga evolucionar los esquemas de forma aditiva; nunca reutilice los números de campo de Protobuf.
  • REST en el perímetro y gRPC entre servicios internos es una separación común y sólida.

A continuación: enrutar y localizar todos estos servicios mediante gateways y descubrimiento.

Preguntas frecuentes

¿La lección «Comunicación entre servicios: REST y gRPC» es gratis?

Sí — el texto completo de «Comunicación entre servicios: REST y gRPC» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de PHP Academy, actualiza a CoddyKit PRO. El curso de PHP Academy incluye 4 lecciones en total.

¿Qué aprenderé en «Comunicación entre servicios: REST y gRPC»?

Conecte servicios de forma síncrona y eficiente Practicas PHP Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar PHP Academy?

No se requiere experiencia previa. PHP Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 2 de 4.

¿Cuánto tiempo toma la lección «Comunicación entre servicios: REST y gRPC»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de PHP Academy?

Sí. Cada lección de PHP Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

  1. Del monolito a los microservicios
  2. Comunicación entre servicios: REST y gRPC
  3. Puertas de enlace de API y descubrimiento de servicios
  4. Resiliencia: circuit breakers y reintentos
← Volver a PHP Academy