首先，雲服務開放的是基礎設施和服務介面，一般是系統級的對接，API一旦開放想要變更就非常困難；
其次，雲服務並非單獨執行，不同的產品實際場景中是互相組合的，需考慮產品間的一致性和互通便利性；
雲服務API數量龐大，為了更方便使用，配套的API查詢、編排、自動化生成SDK等需求也比普通服務強烈；
雲服務的穩定性非常重要，核心產品的穩定性就是客戶的生命線，要求非常高。
選擇支援哪種風格，才能更好地體現業務特性，讓客戶操作起來更加方便；
設計API時能否面向資源設計，相應的工程人員是否具備做這種設計的能力；
針對這種風格工具鏈的支援是否到位，投入產出比如何；
業界流行的趨勢如何，是否需要考慮與其他系統體系的互操作。
Image caption
它可以使API具有更清晰的結構，幫助使用者理解；
它可以幫助對比API與後臺實體關係模型，更容易提供更完整的API服務；
它可以使產品協作更加順暢，對資源的操作也更加規範化；
它可以使雲服務底層平臺實現起來更統一、更方便；
它可以使圍繞API的生態整合起來更加簡單、高效。
在API命名的時候，遵循什麼樣的正規化來確保大體風格相似？動詞、名詞、介詞如何組合才能保持API風格看起來比較統一，降低理解成本？
對於類似的操作，有沒有使用規範？有哪些公共的標準詞彙使得同型別的操作可以比較容易理解，避免使用晦澀奇怪的詞彙（例如讀操作，Read/Query/Describe/List/Get中都在什麼場合使用什麼動詞）？
被廣泛使用的引數如何儘可能保持一致，避免不同產品的表達混亂的情況（例如分頁引數用PageNumber還是PageNum）？
對於常用的場景，例如冪等、分頁、非同步API的設計有沒有統一的規範，避免使用體驗不一致？
錯誤碼應該怎麼設計？公共錯誤碼怎麼統一，業務錯誤碼怎麼表達？
同樣的請求多次提交，是否會重複建立資源？ 請求處理時間過長，客戶端是長時間等待，還是先非同步返回一個任務ID？ 如果需要等待，Timeout最大值是多少？ 如果Timeout最大值達到，客戶端的策略是重試還是放棄 如果最終處理還是失敗了，具體是哪個環節的問題？如何給出準確的錯誤資訊？ 如果非同步方式，非同步處理完成後是主動查詢還是另有通知？ 第三方工具和整合商到哪裡去獲取這些資訊？能不能有標準化的處理？
雲服務API直接面向使用者，由於呼叫量大，變更影響的使用者範圍也更廣，版本變更要非常謹慎；
雲服務有多種形態，主要是公有云、私有云、細分的行業雲等，不同的雲對同樣功能API的要求可能不一樣，API更加多樣化。既要保障不同版本功能正常，又要能快速部署維護不同版本，挑戰很大；
不相容變更的推廣極其困難，很難讓使用者在短時間內快速升級，維護多版本API成本很高；
必須變更的情況，要確保呼叫方能夠及時感知並且平滑切換的技術難度很大。
API剛剛上線尚未打磨充分，貿然開放可能會留下隱患，再想調整為時已晚，所以選擇先不開放。
API本身並非原子化，封裝了若干業務場景，主要目的是最佳化效能或者服務特定的客戶，並不需要開放給所有使用者；而且當業務場景發生變化的時候，調整起來也比較困難，不適合開放出去。
某些API不適合開放給全部使用者，只能部分開放，例如特定行業專業的API。
API僅供特定場景或私有場景使用，需要外部能夠訪問，但是不能開放給使用者。
