設(shè)計方法論

時間：2022-12-26 10:24:41 紫陽學(xué)習(xí)方法我要投稿

相關(guān)推薦

設(shè)計方法論

　　在平凡的學(xué)習(xí)、工作、生活中，大家對設(shè)計方法都再熟悉不過了吧，下面是小編收集整理的設(shè)計方法論，歡迎閱讀與收藏。

　　設(shè)計方法論 1

　　優(yōu)秀的設(shè)計超越了URL、狀態(tài)碼、頭信息和有效負載

　　一般來說， Web API設(shè)計指南的重點是通用的功能特性，比如URL設(shè)計，正確使用狀態(tài)碼、方法、頭信息之類的HTTP功能特性，以及持有序列化的對象或?qū)ο髨D的有效負載設(shè)計。這些都是重要的實現(xiàn)細節(jié)，但不太算得上API設(shè)計。并且正是API的設(shè)計--服務(wù)的基本功能特性的表達和描述方式--為Web API的成功和可用性做出了重要貢獻。

　　一個優(yōu)秀的設(shè)計過程或方法論定義了一組一致的、可重復(fù)的步驟集，可以在將一個服務(wù)器端服務(wù)組件輸出為一個可訪問的、有用的Web API時使用。那就是說，一個清晰的方法論可以由開發(fā)人員、設(shè)計師和軟件架構(gòu)師共享，以便在整個實現(xiàn)周期內(nèi)幫助大家協(xié)同活動。一個成熟的方法論還可以隨著時間的發(fā)展，隨著每個團隊不斷發(fā)現(xiàn)改善和精簡過程的方式而得到精煉，卻不會對實現(xiàn)細節(jié)產(chǎn)生不利的影響。實際上，當(dāng)實現(xiàn)細節(jié)和設(shè)計過程兩者都有清晰的定義并相互分離時，實現(xiàn)細節(jié)的改變(比如采用哪個平臺、OS、框架和UI樣式)可以獨立于設(shè)計過程。

　　API設(shè)計七步法

　　接下來我們要對Richardson和Amundsen合著的《REST風(fēng)格的Web API》一書中所介紹的設(shè)計方法論做簡要地概述。因為幅所限，我們不能深入探討這一過程中的每一步驟，但這文章可以讓你有個大概的認識。另外，讀者可以用這概述作為指南，根據(jù)自己組織的技能和目標(biāo)開發(fā)一個獨有的Web API設(shè)計過程。

　　說明：是的，7步看起來有點兒多。實際上清單中有5個步驟屬于設(shè)計，額外還有兩個條目是實現(xiàn)和發(fā)布。最后這兩個設(shè)計過程之外的步驟是為了提供一個從頭到尾的體驗。

　　你應(yīng)該計劃好根據(jù)需要重新迭代這些步驟。通過步驟2(繪制狀態(tài)圖)意識到在步驟1(列出所有組成部分)有更多工作要做。當(dāng)你接近于寫代碼(步驟6)時，可能會發(fā)現(xiàn)第5步(創(chuàng)建語義檔案)中漏了一些東西。關(guān)鍵是用這個過程暴露盡可能多的細節(jié)，并愿意回退一步或者兩步，把前面漏掉的補上。迭代是構(gòu)建更加完整的服務(wù)畫面以及澄清如何將它暴露給客戶端程序的關(guān)鍵。

　　步驟1 : 列出所有組成部分

　　第一步是列出客戶端程序可能要從我們的服務(wù)中獲取的，或要放到我們的服務(wù)中的所有數(shù)據(jù)片段。我們將這些稱為語義描述符。語義是指它們處理數(shù)據(jù)在應(yīng)用程序中的含義，描述符是指它們描述了在應(yīng)用程序自身中發(fā)生了什么。注意，這里的視點是客戶端，不是服務(wù)器端。將API設(shè)計成客戶端使用的東西很重要。

　　比如說，在一個簡單的待辦事項列表應(yīng)用中，你可能會找到下面這些語義描述符：

　　id : 系統(tǒng)中每條記錄的唯一標(biāo)識符

　　title : 每個待辦事項的標(biāo)題

　　dateDue : 待辦事項應(yīng)該完成的日期

　　complete : 一個是/否標(biāo)記，表明待辦事項是否已經(jīng)完成了。

　　在一個功能完備的應(yīng)用程序中，可能還會有很多語義描述符，涉及待辦事項的分類(工作、家庭、園藝等)，用戶信息(用于多用戶的實現(xiàn))等等。不過為了突出過程本身，我們會保持它的簡單性。

　　步驟2 : 繪制狀態(tài)圖

　　下一步是根據(jù)建議的API繪制出狀態(tài)圖。圖中的每個框都表示一種可能的表示--一個包含在步驟1中確定的一或多個語義描述符的文檔。你可以用箭頭表示從一個框到下一個的轉(zhuǎn)變--從一個狀態(tài)到下一個狀態(tài)。這些轉(zhuǎn)變是由協(xié)議請求觸發(fā)的。

　　在每次變化中還不用急著指明用哪個協(xié)議方法。只要標(biāo)明變化是安全的(比如HTTP GET)，還是不安全/非冪等的(比如HTTP.POST)，或者不安全/冪等的(PUT)。

　　說明：冪等動作是指重復(fù)執(zhí)行時不會有無法預(yù)料的副作用。比如HTTP PUT ，因為規(guī)范說服務(wù)器應(yīng)該用客戶端傳來的狀態(tài)值替換目標(biāo)資源的已有值，所以說它是冪等的。而 HTTP POST 是非冪等的，因為規(guī)范指出提交的值應(yīng)該是追加到已有資源集合上的，而不是替換。

　　在這個案例中，我們這個簡單的待辦事項服務(wù)的客戶端應(yīng)用程序可能需要訪問可用條目的清單，能過濾這個清單，能查看單個條目，并且能將條目標(biāo)記為已完成。這些動作中很多都用狀態(tài)值在客戶端和服務(wù)器之間傳遞數(shù)據(jù)。比如add-item 動作允許客戶端傳遞狀態(tài)值title和dueDate。下面是一個說明那些動作的狀態(tài)圖。

　　這個狀態(tài)圖中展示的這些動作(也在下面列出來了)也是語義描述符-- 它們描述了這個服務(wù)的語義動作。

　　read-list

　　filter-list

　　read-item

　　create-item

　　mark-complete

　　在你做這個狀態(tài)圖的過程中，你可能會發(fā)現(xiàn)自己漏掉了客戶端真正想要或需要的動作或數(shù)據(jù)項。這是退回到步驟1的機會，添加一些新的描述符，并/或者在步驟2中改進狀態(tài)圖。

　　在你重新迭代過這兩步之后，你應(yīng)該對客戶端跟服務(wù)交互所需的所有數(shù)據(jù)點和動作有了好的認識和想法。

　　步驟 3 : 調(diào)和魔法字符串

　　下一步是調(diào)和服務(wù)接口中的所有“魔法字符串”�！澳Хㄗ址� 全是描述符的名稱--它們沒有內(nèi)在的含義，只是表示客戶端跟你的服務(wù)通訊時將要訪問的動作或數(shù)據(jù)元素。調(diào)和這些描述符名稱的意思是指采用源自下面這些地方的，知名度更高的公共名稱：

　　Schema.org

　　microformats.org

　　Dublin Core

　　IANA Link Relation Values

　　這些全是明確定義的`、共享的名稱庫。當(dāng)你服務(wù)接口使用來自這些源頭的名稱時，開發(fā)人員很可能之前見過并知道它們是什么意思。這可以提高API的可用性。

　　說明：盡管在服務(wù)接口上使用共享名稱是個好主意，但在內(nèi)部實現(xiàn)里可以不用(比如數(shù)據(jù)庫里的數(shù)據(jù)域名稱)。服務(wù)自身可以毫不困難地將公共接口名稱映射為內(nèi)部存儲名稱。

　　以待辦事項服務(wù)為例，除了一個語義描述符- create-item，我能找到所有可接受的已有名稱。為此我根據(jù)Web Linking RFC5988中的規(guī)則創(chuàng)建了一個具有唯一性的URI。在給接口描述符選擇知名的名稱時需要折中。它們極少能跟你的內(nèi)部數(shù)據(jù)存儲元素完美匹配，不過那沒關(guān)系。

　　這里是我的結(jié)果：

　　id -> 來自Dublin Core的identifier

　　title - 來自Schema.org的name

　　dueDate -> 來自Schema.org的scheduledTime

　　complete -> 來自Schema.org的status

　　read-list -> 來自IANA Link Relation Values的collection

　　filter-list -> 來自IANA Link Relation Values的search

　　read-item -> 來自IANA Link Relation Values的item

　　create-item ->用RFC5988的http://mamund.com/rels/create-item

　　mark-complete - 來自IANA Link Relation Values的edit

　　經(jīng)過名稱調(diào)和，我的狀態(tài)圖變成了下面這樣：

　　步驟 4 : 選一個媒體類型

　　API設(shè)計過程的下一步是選一個媒體類型，用來在客戶端和服務(wù)器端之間傳遞消息。Web的特點之一是數(shù)據(jù)是通過統(tǒng)一的接口作為標(biāo)準(zhǔn)化文檔傳輸?shù)�。選擇同時支持數(shù)據(jù)描述符(比如"identifier"、"status"等)和動作描述符(比如"search"、"edit"等)的媒體類型很重要。有相當(dāng)多可用的格式。

　　在我寫這文章時，一些頂尖的超媒體格式是 (排名不分先后)：

　　超文本標(biāo)記語言 (HTML)

　　超文本應(yīng)用程序語言(HAL)

　　Collection+JSON (Cj)

　　Siren

　　JSON-API

　　交換表達式的統(tǒng)一基礎(chǔ) (UBER)

　　讓所選擇的媒體類型適用于你的目標(biāo)協(xié)議也很重要。大多數(shù)開發(fā)人員喜歡用HTTP 協(xié)議做服務(wù)接口。然而WebSockets、XMPP、MQTT和CoAP 也會用--特別是對于高速、短消息、端到端的實現(xiàn)。

　　在這個例子中，我會以HTML為消息格式，并采用HTTP協(xié)議。HTML有所有數(shù)據(jù)描述符所需的支持(用于列表，用于條目，用于數(shù)據(jù)元素)。它也有足夠的動作描述符支持 (用于安全鏈接，用于安全轉(zhuǎn)變，用于非安全轉(zhuǎn)變)。

　　注意：在這個狀態(tài)圖中， “編輯”動作是冪等的(比如HTTP PUT)，并且HTML仍然沒有對PUT的原生支持。在這個例子中，我會添加一個域來將HTML的POST做成冪等的。