tag | a7efe3bd6614f9f22e8629ad97295be76cc27852 | |
---|---|---|
tagger | Li Zhanhui <lizhanhui@gmail.com> | Thu Jun 30 10:27:42 2022 +0800 |
object | 0d352dbc5a524176326775e43da39b908ab5c91f |
Release v2.0-alpha Comparing to v1.0, a few changes are introduced: 1. Bi-directional stream API is used, allowing server to issue diagnosing telemetry commands to clients; 2. Server side stream API is employed for receive message API, which mitigates costs of serialization/deserialization of large data chunks 3. Error code are re-organized, roughly following HTTP semantics. Each code now has five digits, first three of them complies HTTP status code; The rest two digits are used to specify each exact scenario. 4. A few concepts are renamed to follow RocketMQ 5.x terminologies.
commit | 0d352dbc5a524176326775e43da39b908ab5c91f | [log] [tgz] |
---|---|---|
author | Aaron Ai <yangkun.ayk@alibaba-inc.com> | Wed Jun 29 19:55:39 2022 +0800 |
committer | GitHub <noreply@github.com> | Wed Jun 29 19:55:39 2022 +0800 |
tree | a911a9a6a1788a520b601420aedd9a7da353dcd5 | |
parent | eb30328910f75c8dff00d86687eb696a9623adae [diff] |
Rename CLIENT_ID_MISSING as CLIENT_ID_REQUIRED (#50)
This API spec adopts a rich error model developed by Google as described here. This model enables servers to return and clients to consume additional error details expressed as one or more protobuf messages. It further specifies a standard set of error message types to cover the most common needs (such as invalid parameters, quota violations, and stack traces).
The whole set of response codes are listed here, except the offical gRPC error model, please refer to service.proto
for more details about the error responses of each RPC service.
Messages and enumerations of the API spec reserve the first 64 fields for the evolution of RocketMQ exclusively. Vendor-specific extensions to the protocol are supposed to use fields beyond 64.