docs: update protobuf links (#22182)

2024-10-09 07:18:53 +00:00
parent 4aeb053925
commit f48fac3e50
12 changed files with 32 additions and 32 deletions
@@ -17,9 +17,9 @@ While encoding in the Cosmos SDK used to be mainly handled by `go-amino` codec,
 ## Encoding

 The Cosmos SDK supports two wire encoding protocols.  Binary encoding is fulfilled by [Protocol
-Buffers](https://developers.google.com/protocol-buffers), specifically the
+Buffers](https://protobuf.dev/), specifically the
 [gogoprotobuf](https://github.com/cosmos/gogoproto/) implementation, which is a subset of
-[Proto3](https://developers.google.com/protocol-buffers/docs/proto3)  with an extension for
+[Proto3](https://protobuf.dev/programming-guides/proto3/)  with an extension for
 interface support.  Text encoding is fulfilled by [Amino](https://github.com/tendermint/go-amino).

 Due to Amino having significant performance drawbacks, being reflection-based, and not having
@@ -52,7 +52,7 @@ Modules are encouraged to utilize Protobuf encoding for their respective types.

 ### Guidelines for protobuf message definitions

-In addition to [following official Protocol Buffer guidelines](https://developers.google.com/protocol-buffers/docs/proto3#simple), we recommend using these annotations in .proto files when dealing with interfaces:
+In addition to [following official Protocol Buffer guidelines](https://protobuf.dev/programming-guides/proto3/#simple), we recommend using these annotations in .proto files when dealing with interfaces:

 * use `cosmos_proto.accepts_interface` to annotate `Any` fields that accept interfaces
    * pass the same fully qualified name as `protoName` to `InterfaceRegistry.RegisterInterface`
@@ -240,5 +240,5 @@ Protobuf types can be defined to encode:

 #### Naming and conventions

-We encourage developers to follow industry guidelines: [Protocol Buffers style guide](https://developers.google.com/protocol-buffers/docs/style)
+We encourage developers to follow industry guidelines: [Protocol Buffers style guide](https://protobuf.dev/programming-guides/style/)
 and [Buf](https://buf.build/docs/style-guide), see more details in [ADR 023](../../architecture/adr-023-protobuf-naming.md)
@@ -181,7 +181,7 @@ Modules must implement [interfaces](../../build/building-modules/01-module-manag

 ### `Msg` Services

-Each application module defines two [Protobuf services](https://developers.google.com/protocol-buffers/docs/proto#services): one `Msg` service to handle messages, and one gRPC `Query` service to handle queries. If we consider the module as a state-machine, then a `Msg` service is a set of state transition RPC methods.
+Each application module defines two [Protobuf services](https://protobuf.dev/programming-guides/proto2/): one `Msg` service to handle messages, and one gRPC `Query` service to handle queries. If we consider the module as a state-machine, then a `Msg` service is a set of state transition RPC methods.
 Each Protobuf `Msg` service method is 1:1 related to a Protobuf request type, which must implement `sdk.Msg` interface.
 Note that `sdk.Msg`s are bundled in [transactions](../advanced/01-transactions.md), and each transaction contains one or multiple messages.

@@ -208,7 +208,7 @@ Each module should also implement the `RegisterServices` method as part of the [

 gRPC `Query` services allow users to query the state using [gRPC](https://grpc.io). They are enabled by default, and can be configured under the `grpc.enable` and `grpc.address` fields inside <!-- markdown-link-check-disable-line -->[`app.toml`](../../user/run-node/01-run-node.md#configuring-the-node-using-apptoml-and-configtoml).

-gRPC `Query` services are defined in the module's Protobuf definition files, specifically inside `query.proto`. The `query.proto` definition file exposes a single `Query` [Protobuf service](https://developers.google.com/protocol-buffers/docs/proto#services). Each gRPC query endpoint corresponds to a service method, starting with the `rpc` keyword, inside the `Query` service.
+gRPC `Query` services are defined in the module's Protobuf definition files, specifically inside `query.proto`. The `query.proto` definition file exposes a single `Query` [Protobuf service](https://protobuf.dev/programming-guides/proto2/). Each gRPC query endpoint corresponds to a service method, starting with the `rpc` keyword, inside the `Query` service.

 Protobuf generates a `QueryServer` interface for each module, containing all the service methods. A module's [`keeper`](#keeper) then needs to implement this `QueryServer` interface, by providing the concrete implementation of each service method. This concrete implementation is the handler of the corresponding gRPC query endpoint.

@@ -41,7 +41,7 @@ The CLI understands a specific set of commands, defined in a hierarchical struct

 ### gRPC

-Another interface through which users can make queries is [gRPC](https://grpc.io) requests to a [gRPC server](../advanced/06-grpc_rest.md#grpc-server). The endpoints are defined as [Protocol Buffers](https://developers.google.com/protocol-buffers) service methods inside `.proto` files, written in Protobuf's own language-agnostic interface definition language (IDL). The Protobuf ecosystem developed tools for code-generation from `*.proto` files into various languages. These tools allow to build gRPC clients easily.
+Another interface through which users can make queries is [gRPC](https://grpc.io) requests to a [gRPC server](../advanced/06-grpc_rest.md#grpc-server). The endpoints are defined as [Protocol Buffers](https://protobuf.dev/) service methods inside `.proto` files, written in Protobuf's own language-agnostic interface definition language (IDL). The Protobuf ecosystem developed tools for code-generation from `*.proto` files into various languages. These tools allow to build gRPC clients easily.

 One such tool is [grpcurl](https://github.com/fullstorydev/grpcurl), and a gRPC request for `MyQuery` using this client looks like: