The goal is to provide REST adapters for RRPC APIs, enabling non-RRPC developers or systems to access RRPC endpoints via REST if needed. Unlike conventional API generation approaches, this feature focuses on optional, configurable adapters that extend RRPC functionality. It targets accessibility rather than replacing RRPC's core functionality.
Additionally, the design will explore supporting Google's built-in REST configuration model (such as google.api.http annotations in protobuf) to align with existing standards.
Rationale
RRPC is designed around RSocket, providing native support for streaming and request-response communication patterns. However, not all environments or users may be ready or willing to adopt RSocket due to its complexity or limited use cases.
By offering REST adapters:
Broader Adoption: Developers unfamiliar with RSocket can access the product via REST.
System Integration: REST is ideal for environments where integrating RSocket would add unnecessary overhead.
Backward Compatibility: REST adapters allow RRPC-powered products to be consumed by legacy systems.
Extensibility: Aligning with Google’s REST annotation model ensures flexibility and future compatibility.
Proposed Implementation
REST Adapter Design
Configurable Adapters:
REST endpoints are optional and generated only if configured by the developer.
Adapters allow selective exposure of RRPC services via REST.
Route Mapping:
RRPC methods are mapped to RESTful endpoints based on configurable rules or annotations.
Default mapping:
Request-response RPCs are mapped to standard HTTP methods (e.g., GET, POST).
Extend to support custom mapping via google.api.http annotations.
Serialization and Validation:
Input and output data are serialized/deserialized to/from JSON.
Validate input to match RRPC service contracts before forwarding the request.
Adapter Lifecycle:
The adapter listens for REST requests and delegates them to the corresponding RRPC handlers.
Errors from RRPC are translated to HTTP status codes and JSON error messages.
Implementation Plan
Phase 1: Request-Response Support
Adapter Generator:
Build adapters dynamically using the RRPC service descriptor.
Parse google.api.http annotations, if present, to define routes and HTTP methods.
Middleware:
Create middleware to:
Convert REST requests to RRPC calls.
Map RRPC responses to HTTP responses.
Default mapping if no custom annotations are provided.
Testing:
Focus on integration testing with REST clients consuming RRPC services.
Validate behavior with and without custom annotations.
Documentation:
Explain how to enable REST adapters and use them with RRPC.
Phase 2: Advanced Features
Streaming Support:
Simulate streaming patterns using chunked responses or HTTP/2 where possible.
Explore WebSocket-based alternatives for more complex streaming use cases.
Custom Configuration:
Allow custom route definitions, headers, and query parameters.
Summary
The goal is to provide REST adapters for RRPC APIs, enabling non-RRPC developers or systems to access RRPC endpoints via REST if needed. Unlike conventional API generation approaches, this feature focuses on optional, configurable adapters that extend RRPC functionality. It targets accessibility rather than replacing RRPC's core functionality.
Additionally, the design will explore supporting Google's built-in REST configuration model (such as
google.api.http
annotations in protobuf) to align with existing standards.Rationale
RRPC is designed around RSocket, providing native support for streaming and request-response communication patterns. However, not all environments or users may be ready or willing to adopt RSocket due to its complexity or limited use cases.
By offering REST adapters:
Proposed Implementation
REST Adapter Design
Configurable Adapters:
Route Mapping:
GET
,POST
).google.api.http
annotations.Serialization and Validation:
Adapter Lifecycle:
Implementation Plan
Phase 1: Request-Response Support
Adapter Generator:
google.api.http
annotations, if present, to define routes and HTTP methods.Middleware:
Testing:
Documentation:
Phase 2: Advanced Features
Supporting Google's REST Model
google.api.http
:Example Usage
Protobuf Service Definition:
Exposed REST Endpoints:
GET /v1/books/{id}
(fromgoogle.api.http
)POST /BookService/ListBooks
(default mapping for unannotated RPC)REST Request Flow:
GET /v1/books/123
.GetBook
.Minimal goals
google.api.http
annotations.Next Steps