例子：

service Backup {
    // 备份恢复 post 请求
    rpc Restore (RestoreRequest) returns (RestoreResponse) {
        option (google.api.http) = {
            post: "/v1/restoreVmBackup"
            body: "*"
        };
    }
 
    // 查看备份恢复记录 get 请求
    rpc Filter (FilterRequest) returns (FilterResponse) {
        option (google.api.http) = {
            get: "/v1/filterBackup"
        };
    }
    // 内部使用请求
    rpc Search (SearchRequest) returns (SearchResponse);
}
 
 
message RestoreRequest {
    // 备份id
    int64 backupId = 1;
    // 是否强制关机
    bool poweroff = 2;
}
 
message RestoreResponse {
    // 一个 API 请求的唯一标识
    string requestId = 1;
    // 返回的请求状态
    status.ResponseStatus status = 2;
}

1、RPC Service服务名称必须是名词，首字母大写，多个单词使用驼峰命名风格。

2、RPC方法名称必须是动词，首字母大写，多个单词使用驼峰命名风格。

3、HTTP method只使用POST和GET两种请求方式。

4、路径统一为：/<版本号>/<rpc方法名><service名称>，多个单词使用驼峰命名风格，列表接口使用复数形式。

5、GET参数和POST内容体参数统一使用驼峰。

6、常量必须全部是大写字母，单词之间用下划线分割。

7、内部使用接口不需要提供http api访问

8、加上备注

需要注意的点：

1、禁止修改字段序号
2、禁止修改字段类型
3、禁止修改字段名称
4、禁止删除字段
5、禁止删除RPC接口
6、禁止修改RPC接口签名
7、禁止新增使用reserved字段
8、禁止删除reserved字段

简单来说：proto不删字段，不改字段，一般只新增字段，新增需要加到message最后，不能改变原有的序号。

9、新proto文件，包名命名问题

为了避免引用多个proto包名重名问题，确保proto文件的包名和文件名不一样，一般按照公司或者组名区分

10、proto互相引用问题：

为了避免循环引用，需要遵循以下规则

避免出现A import B, B import C， C又 import A

公用部分可以统一放在公共的common.proto中

A import common.proto

B import common.proto

如果一个已经存在的消息类型不再能满足需求，比如，添加额外的字段等。在不破坏现有的消息类型更新非常简单，但是要遵守一下规则：

• 不要更改现有的任何字段的字段编号。
• 添加新字段时，老的消息格式序列化仍旧可以被新的解析，新的字段会以默认值出现。同样新的消息格式序列化也可以被旧的解析，但是会忽略新字段。 兼容性
• 删除字段时，要保证新的字段编号不与删除的相同。重命名该字段，或者添加 OBSOLETE_ 前缀，或者使用 reserved 关键字。 以确保将来的用户不会复用之前的字段编号。
• int32 uint32 int64 uint64 和 bool 都是兼容的 - 也就是说你可以再它们之间修改字段的类型，而不会破坏向前或者向后兼容性。 如果解析中的字段类型不同，会发生自动类型转换。如果字节数变少了，会自动截断。
• sint32 和 sint64 相互兼容，但与其它类型不兼容。
• string 和 bytes 只要是有效的 UTF-8 ，相互兼容。
• 如果字节包含消息的编码版本，则 bytes 和内嵌消息兼容。
• fixed32 跟 sfixed32 兼容， fixed64 和 sfixed64 兼容。
• enum 和 int32 uint32 int64 uint64 兼容（如果值不同，自动截断）。但要注意，反序列化消息时，客户端代码可能会以不同的方式对待它们： 比如，无法识别的 proto3 enum 类型会保留在消息中，在反序列化消息时如何表达取决于具体的语言。 int 字段只是保留其值。

如果避免不了需要删除，则需要把删除字段新增到reserved 中

message 中的字段可能被删除或者注释，一旦未来之前的字段编号被复用。可能会导致严重的问题，比如数据损坏和一些隐藏的 bug 等。 所以要确保已经废弃的字段编号不会被再次使用。一种解决办法是显式的用 reserved 指定已经被删除的字段编号。如果将来有人使用了，编译器会做出提示。

甚至可以使用 max 关键字来表示最大字段编号值。比如 40 to max 表示 40 到 max 之间的全部保留。注意，在 reserved 值中不可混用字段编码和字段名。