例子：

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 值中不可混用字段編碼和字段名。