Openstack API 類型 & REST 風格

目錄

Openstack 提供了三種操做方式

Web界面

也就是經過Dashboard(儀錶板)來使用Openstack雲計算平臺上的功能。經過Web界面使用 OpenStack Services 這種方式是經過 OpenStack Horizon Project 提供的。Horizon Project 是一個Django Web Application。Horizon Project 會經過API來和各個 OpenStack Services 進行交互,而後在 Web 界面上顯示這些 Services 的狀態和交互結果。html

CIL 指令行

經過以往的 keystone、nova、neutron 等指令,或者經過最新的 OpenStack 指令來操做各個 Services 的功能。社區目前但願使用統一的 OpenStack 指令來代替以往每一個 Project 都有各自的 Commands 的方式,這些 Commands 是由命名爲 client(EG. keystoneclient、novaclient) 的項目所實現的。這些 client 項目除了爲用戶提供命令行操做界面方式以外還提供了 Python 的 SDK (實際上是在SDK的基礎上實現了命令行)。這些 client 項目提供的 SDK 本質是封裝了這些 Openstack services 的 API 的調用。現在 Openstack 社區但願僅使用 openstackclient 做爲統一的命令行工具,而後使用各個 Services 的 client 項目所提供的 SDK 來完成相應的操做。nginx

RESTful API

經過各個 OpenStack Project 提供的 API 來使用各 Services 的功能。API 這種方式是支撐上述兩種方式的基礎,由各個 Services 自身來實現使用 API 操做 OpenStack 的方式。這些 API 具備統一的形式,均採用了基於 HTTP 協議的 Restful 風格來實現。Openstack API 服務進程在接收了客戶端的HTTP Request以後,一個所謂的 路由 模塊就會將URL轉換成爲相應的資源,並路由到合適的操做函數上去。以此來實現了從API到具體操做的映射。web

REST 風格

REST(Representational State Transfer)表述性狀態轉換,是一種軟件架構的設計風格,而不是一種標準,爲軟件設計提供了一組原則和約束條件,但這是原則和約束的條件也一樣不具備標準性。因此也能夠將REST理解爲是一組沒有嚴格標準的架構約束條件和設計原則。REST的軟件設計傾向於簡單輕量的方法設計和實現,以及**REST具備經過HTTP直接傳輸數據的特性。**REST風格的軟件架構必須知足下面兩點規範:sql

  • URI 標識資源:首先從Restful的角度來看,互聯網上的任何東西(文本/圖片/視頻/歌曲/Services)都是一個資源。每一個資源都使用了一個特定的URI來惟一標示,訪問這一個URI就是訪問這一個資源,並且這個資源具備至少一種狀態。api

  • 無狀態原則: 再一個就是,Client 和 Server 之間互相傳遞的只是資源的表述,即:調用資源的URI並獲取資源的不一樣表現形式。而且 Client 和 Server 之間的交互是由 HTTP 無狀態協議來支撐的,因此資源的全部狀態都只會保存在 Server 中。當 Client 應用 HTTP 協議中的 GET/POST/PUT/DELETE 操做資源時,會使得 Server 中的資源的狀態發生轉換,這就是所謂的「表述性狀態轉換」。安全

RESTFul風格的API設計

你的URI中應該都是名詞,表示一個事物,而非動詞。EG. /resources/142 是好的URI,它看起來像是一個事物 而 /resources/142/get 則不是好的URI,由於它看起來更像是一個動做,只有事物才符合資源的定義。restful

  • 面向資源的體系結構
  • URI使用名詞,不使用動詞
  • 資源地址即URI
  • 無狀態性
  • 靈活使用單數和複數
  • 傳輸資源的表現形式(Web Server 接收和返回的互聯網媒體類型,JSON/XML)
  • 對資源的操做與HTTP內置方法映射

基於HTTP協議的RESTful API

因爲這種軟件設計風格很是適合採用HTTP協議來實現,所以HTTP協議是目前實現RESTful API的主要方案。session

OpenStack 就是基於 HTTP 協議和 JSON 來實現本身的 RESTful API(以前OpenStack還有采用XML來表示數據的,如今都已經轉到JSON了)。當一個 Service 要對外提供 API 時,它就會啓動一個 HTTP Web Server,用來對外提供 RESTful API。架構

OpenStack 的 API 都是有詳細的文檔記錄的,能夠查看全部的API文檔框架

OpenStack 的 API 服務都是使用 WSGI 的方式來部署的。部署WSGI,通常會使用 Web Server + Application Server + Application(框架) 的部署方式。OpenStack 官方推薦的是使用 Apache + mod_wsgi ,固然你也能夠選 nginx + uWSGI 。還有些項目會提供使用 eventlet 的單進程部署方案(EG. Keystone項目的keystone-all命令)。

OpenStack中的RESTful API開發框架

OpenStack 早期的核心項目(EG. Keystone/Nova/Glance/Neutron)使用了由幾個模塊組合出來的一個框架: Paste + PasteDeploy + Routes + WebOb 。這些模塊分別負責了應用的 WSGI 化、URL 路由和請求處理等功能。可是這種框架存在着較爲複雜的弊端,因此如今 Openstack 社區的新項目已經開始使用新的 Web 框架 Pecan。

Pecan 是一個基於對象路由的框架,即靈活又簡單。Pecan 主要實現了 URL 路由功能,支持 RESTful API 。Pecan 沒有實現模板、session 管理、 ORM 等功能,可是這些功能能夠經過其餘的模塊來實現。對於 OpenStack 來講,Pecan 是一個很好的選擇,由於 OpenStack 項目中統一使用 sqlalchemy 來實現ORM,API的實現也不須要模板功能,安全控制則基於 Keystone 體系。使用 Pecan 來開發 REST 服務,代碼量不多,代碼結構也清晰。

相關文章
相關標籤/搜索