> 原文出處：http://www.infoq.com/cn/articles/description-discovery-profiles-primer [TOC] ## Web API的下一階段 雖然Web API的實現正變得越來越普及，但在工具方面還缺乏一些被廣泛接受的標準，用以描述、發現，并且理解大量基于API的服務的意義。如何圍繞著API的“元層面”對工具進行定義與實現，這方面仍然存在著大量的機會。 從目前來看，在以下三個領域方面，人們持續地表現出關注的態度以及開展實際的工作。這幾個領域分別是： ### 描述 API描述指的是以一種讓人類與機器都可讀的形式對API進行描述，包括API的實現細節，例如資源與URL、表述格式（HTML、XML、JSON等等）、狀態碼以及輸入參數。在這一領域方面，有幾個關鍵的帶頭者正處于前沿的位置。 ### 發現 API發現是指按照一些特定的條件（例如上線時間、許可、定價以及性能限制），尋找以及選擇能夠提供所需服務（例如購物、用戶管理等等）的Web API的過程。目前來說，這一過程主要還是由人類驅動的，但已經出現了一些工具，試圖將這一過程中的某些部分實現自動化。 ### 檔案 “檔案”一直以來都是圖書管理員與信息科學家所關注的內容，它定義了API請求與響應中所包含的詞匯表術語的含義與使用方式。隨著Web API的發展，檔案也重新獲得了技術人員的關注。雖然它依然是一種實驗性質的思想，但有跡象顯示，API的提供者與設計者正在開始實現對Web API檔案的支持。 本文將對Web API元數據的這三個方面進行一次簡單的回顧，并指出每個領域中的關鍵性工具與發展趨勢。 ## 描述API的實現 目前，對于API的設計與實現的關注主要集中于它的描述格式。如今經常為人提及的格式包括[Swagger](http://swagger.io/)、[RAML](http://raml.org/)以及[API Blueprint](https://apiblueprint.org/)，但其實現有的格式可以舉出長長的一列。這些格式各自采取了一種略有不同的設計方式，但在本質上都提供了相同的基本特性：以多種不同級別的細節對Web API進行描述。 ### API優先 現如今，大多數設計方式都支持API優先的概念。你首先以某種基于XML、JSON或YAML的元語言描述你的API，并通過生成的文檔（或文檔集）自動生成一些實現方面的元素，例如服務端代碼、人類可讀的文檔、測試harness、SDK，甚至是包含完整功能的API客戶端。 API優先設計方式的一個例子是由[Apiary](https://apiary.io/)所推出的[API Blueprint](https://github.com/apiaryio/api-blueprint#api-blueprint)格式。它是一種基于[Markdown](http://daringfireball.net/projects/markdown/)的格式，目標是支持人類可讀的API描述，同時又保證它的機器可讀性。在以下示例中，你可以看到一個單一的資源（/message），它支持GET與PUT兩種方法。你還可以看到其中對人類可讀的文本的支持，以描述操作該API的方法。 **API Blueprint****描述示例** ~~~ FORMAT: 1A # Resource and Actions API This API example demonstrates how to define a resource with multiple actions. # /message This is our resource ## GET Here we define an action using the `GET` HTTP request method. As with every good action it should return a response + Response 200 (text/plain) Hello World! ## PUT OK, let's add an update action and send a response back confirming the posting was a success + Request (text/plain) All your base are belong to us. + Response 204 ~~~ [RAML](http://raml.org/)、[Swagger](http://swagger.io/)以及其它一些類似格式的工作方式也是大同小異。 在采用API優先方式時，你需要通過工具將設計時創建的元語言轉換為可以在運行時起作用的東西。舉例來說，Swagger的[codegen](https://github.com/swagger-api/swagger-codegen)工具能夠解析描述文檔，并生成相應的客戶端代碼。而[RAML-for-JAX-RS](https://github.com/mulesoft/raml-for-jax-rs)項目則在RAML描述與通過JAX-RS進行注解的Java代碼之間提供雙向轉換的功能。 ### 代碼優先 支持代碼優先方式的描述模型為數極少，這種方式是通過源代碼生成服務描述。不過，這一領域中最知名的格式 ——?[Web Service描述語言](http://www.w3.org/TR/wsdl)（WSDL）在企業級應用社區中仍然相當流行，并且支持WSDL的工具為數眾多，像微軟的[Visual Studio](https://www.visualstudio.com/)與[Eclipse](https://eclipse.org/)等常見的編輯平臺都提供了對它的支持。 下面是通過WSDL對某個簡單的Web API進行描述的一個示例。 **HelloService WSDL****示例** ~~~ <definitions name="HelloService" targetNamespace="http://www.examples.com/wsdl/HelloService.wsdl" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://www.examples.com/wsdl/HelloService.wsdl" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <message name="SayHelloRequest"> <part name="firstName" type="xsd:string"/> </message> <message name="SayHelloResponse"> <part name="greeting" type="xsd:string"/> </message> <portType name="Hello_PortType"> <operation name="sayHello"> <input message="tns:SayHelloRequest"/> <output message="tns:SayHelloResponse"/> </operation> </portType> <binding name="Hello_Binding" type="tns:Hello_PortType"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="sayHello"> <soap:operation soapAction="sayHello"/> <input> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:examples:helloservice" use="encoded"/> </input> <output> <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:examples:helloservice" use="encoded"/> </output> </operation> </binding> <service name="Hello_Service"> <documentation>WSDL File for HelloService</documentation> <port binding="tns:Hello_Binding" name="Hello_Port"> <soap:address location="http://www.examples.com/SayHello/" /> </port> </service> </definitions> ~~~ 如果選擇了代碼優先方式，那么你就需要通過某些工具，將你的源代碼轉換為可重用的API描述元數據。Eclipse與Visual Studio都可以一鍵實現通過代碼生成WSDL文件。另外還有一些工具能夠讀取WSDL文件，并生成各種實現元素。例如[SmartBear](http://smartbear.com/)的[SoapUI](http://www.soapui.org/soap-and-wsdl/working-with-wsdls.html)工具就能夠基于WSDL文件生成代碼、創建人類可讀的文檔，甚至是進行構建與運行測試集等任務。  **圖1\. SoapUI能夠讀取WSDL文件** ### 將API文檔化 大多數API描述格式同樣支持生成人類可讀的文檔，包括RAML、Apiary和 Swagger。實際上，開源的[Swagger-UI](https://github.com/swagger-api/swagger-ui)工具就是以文檔生成器而聞名的（見下圖），甚至讓某些人產生了一種誤解，認為Swagger僅僅是一種用于生成人類可讀的API文檔的工具。  **圖****?2.?****由****Swagger-UI****工具生成人類可讀的文檔** 有一些描述格式在設計時就專注于生成人類可讀的文檔，Mashery的[I/O Docs](http://www.mashery.com/product/io-docs)就是這方面的一個絕佳例子（見下圖），它同時還提供測試方面的支持。 **Mashery****的I/O Docs****示例** ~~~ { "name": "Lower Case API", "description": "An example api.", "protocol": "rest", "basePath": "http://api.lowercase.sample.com", "publicPath": "/v1", "auth": { "key": { "param": "key" } }, "headers": { "Accept": "application/json", "Foo": "bar" }, "resources": { "Resource Group A": { "methods": { "MethodA1": { "name": "Method A1", "path": "/a1/grab", "httpMethod": "GET", "description": "Grabs information from the A1 data set.", "parameters": { "param1": { "type": "string", "required": true, "default": "", "description": "Description of the first parameter." } } }, "MethodA1User": { "name": "Method A1 User", "path": "/a1/grab/{userId}", "httpMethod": "GET", "description": "Grabs information from the A1 data set for a specific user", "parameters": { "param1": { "type": "string", "required": true, "default": "", "description": "Description of the first parameter." }, "userId": { "type": "string", "required": true, "default": "", "description": "The userId parameter that is in the URI." } } } } } } } ~~~ ### 描述與發現并非一回事 不過，無論你的專注點是通過元語言生成代碼，或是由代碼生成文檔（或者其它任何一種方式），API描述只是整個創建與部署Web API流程中的一個環節而已。這一流程中還包括另一個重要環節，就是了解有哪些“現有”的API與服務，以及怎樣使用它們。為了實現這一環節，你需要去發現這些API。 ## 發現現實世界中的API API發現是指定位某個能夠完成特定任務所必須的Web API的能力。舉例來說，你可能需要某個Web API，以實現在線購物、管理用戶帳號或處理幫助平臺上的請求的功能。在實際應用中，你應當能夠以最小的代價發起一次搜索、找到符合你需求的API、獲得訪問該API的能力、實現對接代碼并且開始使用該API。 可惜，現實情況總是有所差異的。 在討論API發現時，我們通常所指的是應用程序編程接口（API）與一個實際 “運行中”的服務這兩者之一。對于前一種情況來說，所討論的內容只是一個接口，我們將用這個接口設計、實現以及部署屬于自己的服務。而對后一種情況來說，我們所指的是某個現有的服務實例本身，你可以遠程連接到這個服務中，并立即開始使用。由于這兩種情況所面臨的困難以及所產生的好處各不相同，因此應當通過示例進行一些考查。 ### API Commons 如果你所尋找的只是一種已經發布的API規范，并且能夠自己完成它的實現，那么[API Commons](http://apicommons.org/)是一個很好的資源。API Commons的目的在于“為API規范、接口以及數據模型提供一種簡單而透明的機制，讓用戶能夠以協作的方式共享無版權歸屬的設計”。打個比方，如果你已經設計了一種API，并且樂于將它的設計分享給他人，讓他們利用你設計的模型實現自己的服務，你就可以將自己的模型發布在API Commons上，并鼓勵其他人使用。 另一方面，如果你打算實現某個API，而又想知道是否已經有人處理了相同的問題，那么你可以API Commons中進行一番搜索，看看有沒有什么現成的設計可以使用。這種發布/訂閱模式能夠促使相似的服務重用相同的接口，而無需與參與者之間討論協作的細節。在最理想的情況下，如果某個API調用者需要使用API Commons上所注冊的某個API的設計，那么他也應當能夠使用實現了相同設計的任何一種服務。 API Commons的運維模式得到了[Creative Commons](http://creativecommons.org/)的啟發，目前由[Kin Lane與Steve Willmott](http://apicommons.org/contact.html)負責維護。 ### 可搜索的服務列表 在多數情況下，當人們談及API發現時，他們所指的其實是發現某個能夠利用的運行實例，即某個可用的服務。目前已經出現了一定數量的服務，它們將追蹤實際的可用服務，并且大多數這種服務都是設計為人類可讀的搜索引擎。其中最著名的一個例子就是Programming Web的[API目錄](http://www.programmableweb.com/apis/directory)（見下圖）  **圖****3\. Programmable Web****的搜索界面** 當你的需求滿足下表中的任意一條時，就可以考慮這種解決方案： * 搜索能夠滿足你的條件的服務 * 對于看起來能夠滿足你需求的API進行評估 * 參與該服務的接入過程，以及最后一條 * 編寫你的API調用代碼，以匹配你所選擇的服務的API 你所選擇的服務有可能會支持一種或多種我們已在上文中涵蓋的API描述語言，這將簡化你創建對應的API調用代碼的工作。 這種發現服務有一個潛在的缺點，那就是并非所有的服務目錄都經過了認真地審查（某些目錄要依賴于“手動注冊過程”）。你在這一過程中可能會找到一些有問題的API，它們或許不支持你所需的協議或格式，并且不再更新、或者無法滿足你在性能與許可方面的需求，等等。此外，如果你打算使用多個第三方API，那么整個搜索、評估、接入以及接口生成循環可能會顯得相當冗長。 ### 聚合服務 除此之外，還存在著另一種類型的API發現方式，即API聚合器。這些聚合器就如同一個或多個現有web service的某種代理，并提供一個單一的、統一的API，方便你進行編碼。這方面的一個例子是Intel的[Mashery API Network](http://developer.mashery.com/)。  **圖****4\. Mashery****的****API Network** 如果你計劃調用多個第三方的Web API，那么聚合器能夠讓你在接入以及API整合方面所需付出的精力大大減少。聚合服務能夠調用后端的API并進行正規化、管理你的訪問密鑰、某些服務甚至能夠為你提供一個自定義的API，通過它簡化在每個第三方API中共享關聯數據的任務。 ### 可配置的運行時發現能力 人們還可以以另一種方式來看待這些API發現服務，即將其視為一種可配置的本地服務發現引擎。這種發現引擎只存在于某個公司的邊界范圍之內，并處理尋找以及連接到一或多個運行中的服務實例的工作，例如某個數據存儲或業務組件。最近幾年來，這種方式正在不斷地發展中，這方面的例子包括[Apache Zookeeper](http://zookeeper.apache.org/)、HashiCorp的[Consul](https://www.consul.io/)、以及CoreOS的[etcd](https://coreos.com/etcd/)等等。  **圖****?5\. Apache Zookeeper****以及****?HashiCorp****的****Consul****提供了在企業內部進行運行時發現的功能。** 這種發現方式的一大優勢在于，當你準備連接到組織內部的運行服務時，它提供了一個額外的間接層。你可以在運行代碼中移除實際的服務地址與連接參數，并將這部分信息保存在配置文件中。某些服務甚至還允許你對于延遲與響應性進行一些限制，讓它自動忽略或跳過運行時間較長的、或是不可用的服務實例，并連接至下一個可用的、健康的實例。 當然，這種抽象也存在著負面的因素。首先，由此產生的復雜性只有在大型服務中才值得一試。其次，對于這種服務的配置模型還沒有實現標準化，這意味著你會最終對于某個提供商產生強依賴關系。最后，這種運行時的發現服務目前還無法用于組織之外的、公開的第三方服務。 ### 通過APIs.io與APIs.json實現Web規模的發現功能 與API的單一資源集合相對的是[APIs.io](http://apis.io/)的分布式搜索概念，APIs.io是由[3Scale](http://www.3scale.net/)與來自[API Evangelist](http://apievangelist.com/)的Kin Lane共同合作的成果。它是一種典型的搜索引擎，它本身并不負責托管API文檔，而是跟蹤互聯網上找到的所有發現文件，并為這些文件中的數據提供一個搜索界面。 這些發現文件都是以一種名為[APIs.json](http://apisjson.org/)的格式所生成的。與API描述文檔不同，APIs.json文件并不包含可用的URL、表述形式以及響應代碼的詳細信息，而是包含了指向這些描述文檔位置的指針，以及指向服務條款、許可、聯系方式以及其它相關數據的指針。 這一格式出現的時間很短，但它或許能夠提供一種“粘合劑”，將API的描述與其它數據連接至一個單一的位置。由于這一格式也是機器可讀的，因此它或許能夠幫助搜索功能、甚至是Web API的上線細節實現自動化。 ### 描述與發現仍停留在細節層面 API描述與API發現的共同目標是簡化構建與定位Web API的工作，但它們將大量的精力都專注于低層面的實現細節中，例如如何描述協議方法、返回代碼以及響應的格式。對于編寫實際代碼來說，它們固然非常重要，但有時仍不足以實現設計優秀API的任務。由于它們的多數設計方式都專注于實現細節，因此往往只能描述某個運行中的服務的單一實例（或鏡像集群）的特性。 如果你希望專注于更高層面的設計（例如用例、輸入與輸出），而不是充斥著協議、表述與資源的細節，那么你還需要別的工具。 ## 通過檔案達成共識 在API元服務的開發中的一個最新趨勢是創建與共享API檔案信息的想法。與描述文檔不同，檔案文檔提供了一個更高層次的視圖，它描述了API所支持的功能，在有些情況下還能夠描述客戶端與服務器如何以一種機器可讀的方式暴露它們的特性。 ### Web檔案的歷史簡介 Web檔案的出現已經有很長一段時間了，在1999年出現的[HTML 4.01](http://www.w3.org/TR/html4/cover.html)規范中就引入了檔案這一屬性。[元數據檔案](http://www.w3.org/TR/html4/struct/global.html#h-7.4.4.3)可以定義為 a) 一個全局唯一的名稱 （URI），或 b) 指向一個實際文檔的鏈接（URL）。它的設計理念是讓文檔的作者得以為響應中的內容提供額外的描述性信息（例如文檔的實用索引屬性、服務條款等等）。 在2003年，[Tantek ?elik](http://tantek.com/)定義了[XHTML元數據檔案](http://gmpg.org/xmdp/)（XMDP）。XMDP支持定義同時實現人類可讀與機器可讀的文檔檔案（是不是聽上去有點熟悉？），這種文檔實際上看起來與如今的API描述格式非常相像（參考以下示例）。 **XMDP****的一個示例** ~~~ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head><title>sample HTML profile</title></head> <body> <dl class="profile"> <dt id='author'>author</dt> <dd>A person who wrote (at least part of) the document.</dd> <dt id='keywords'>keywords</dt> <dd>A comma and/or space separated list of the keywords or keyphrases of the document.</dd> <dt id='copyright'>copyright</dt> <dd>The name (or names) of the copyright holder(s) for this document, and/or a complete statement of copyright.</dd> <dt id='date'>date</dt> <dd>The last updated date of the document, in ISO8601 date format.</dd> <dt id='identifier'>identifier</dt> <dd>The normative URI for the document.</dd> <dt id='rel'>rel</dt> <dd> <dl> <dt id='script'>script</dt> <dd>A reference to a client-side script. When used with the LINK element, the script is evaluated as the document loads and may modify the contents of the document dynamically.</dd> </dl> </dd> </dl> </body> </html> ~~~ 遺憾的是，檔案屬性沒有得到廣泛的應用，并且在HTML 5發布時從規范中被刪除了，只能通過其它方式獨立地[定義檔案屬性](http://dev.w3.org/html5/profiles/drafts/ED-html5-profiles-20100522/)。 在檔案屬性從HTML規范中移除之后，[Erik Wilde](http://dret.net/netdret/)提出了[RFC6906](https://tools.ietf.org/html/rfc6906)規范，定義了[Link Relation Value](http://www.iana.org/assignments/link-relations/link-relations.xhtml)這種檔案，并注冊在[互聯網號碼分配局](http://www.iana.org/)（IANA）中。Wilde的想法是將URI風格的檔案進行標準化，通過一種不透明的標識符，“允許資源表述指定它們是否遵循了一種或多種檔案”。 由于我們能夠將響應的細節以檔案的形式進行描述，因此人們開始不僅將檔案應用于人類可讀的文檔，并且也應用在API的響應中。在最近幾年中也出現了一些URL風格的檔案實現。在本文中，我將介紹其中的兩種：DCAP與ALPS。 ### 都柏林核心應用檔案（DCAP） 在2009年，[都柏林核心元數據啟動計劃](http://dublincore.org/)（DCMI）發布了由他們設計的[DCAP](http://dublincore.org/documents/profile-guidelines/)格式，用于描述檔案元數據。DCAP專注于支持資源描述框架（RDF）文檔，它“定義了元數據記錄，以此滿足特定的應用程序需求。同時在全局定義詞匯表與模型的基礎上，提供了與其它應用程序在語義上互操作的能力。” 以下是DCAP文檔的一個示例： **DCAP****文檔示例** ~~~ Description template: Person id=person minimum = 0; maximum = unlimited Statement template: givenName Property: http://xmlns.com/foaf/0.1/givenname minimum = 0; maximum = 1 Type of Value = "literal" Statement template: familyName Property: http://xmlns.com/foaf/0.1/family_name minimum = 0; maximum = 1 Type of Value = "literal" Statement template: email Property: http://xmlns.com/foaf/0.1/mbox minimum = 0; maximum = unlimited Type of Value = "non-literal" value URI = mandatory ~~~ 創建DCAP的原因是因為如今的表述格式（RDF）非常受限，并且過于泛用（例如元組），在這種情況下，DCAP能夠改進共享數據語義的能力。DCAP的一個關鍵優勢在于，它并不是直接指出在響應中使用了哪些術語（例如givenName、familyName、customer、user等等），而是指出這些術語是如何進行通信的。這種方式為創建可共享的在線詞匯表鋪平了道路。 目前已經出現了一部分與DCAP相關的工具，包括在線編輯器、驗證功能以及HTML的生成器。但DCAP的使用主要限制于圖書館、信息科學與學術社區等領域，很少看到將DCAP用于業務相關的Web API中。 ### 應用級別的檔案語義（ALPS） 在2013年，Leonard Richardson、Mark Foster與我共同發布了[ALPS互聯網草案](http://tools.ietf.org/html/draft-amundsen-richardson-foster-alps-01)的第一個版本。與DCAP類似，ALPS同樣借用了XDMP的思想，它為數據元素（例如userName、userStatus等等）與用例元素（例如find-user等等）都提供了元數據。 以下是通過一個ALPS文檔描述一個簡單的搜索API的示例： **由ALPS****文檔所描述的搜索API** ~~~ { "alps" : { "version" : "1.0", "doc" : { "href" : "http://example.org/samples/full/doc.html" }, "descriptor" : [ { "id" : "find-user", "type" : "safe", "doc" : {"value" : "User search form" }, "descriptor" : [ { "id" : "userName", "type" : "descriptor", "doc" : { "value" : "input for search" } }, { "href" : "#userStatus" } ] }, { "id" : "userStatus", "type" : "descriptor", "description" : {"value" : "results filter"}, "ext" : [ { "href" : "http://alps.io/ext/range", "value" : "active,inactive" } ] } ] } } ~~~ ALPS文檔專注于接口層面的互動，按[Eric Evans](https://twitter.com/ericevans0)的話來說也就是[邊界上下文](http://martinfowler.com/bliki/BoundedContext.html)。ALPS并不會處理一些實現方面的細節，例如協議（HTTP、XMPP等等）、格式（HTML、JSON等等）甚至是資源的URL。由于它無需關注實現細節，因此ALPS文檔能夠作為API設計工具的原始資料，以生成人類可讀的文檔，甚至可作為發現過程中的一個環節，幫助你選擇一個合用的API。 目前，對于ALPS最佳的描述是將其視為一個“不穩定的”規范，并且在網上關于如何使用它的示例也非常罕見。[Ronnie Mitra](https://twitter.com/mitraman)設計了一個實驗性質的[Rapido API設計器](https://github.com/apiacademy/rapido-spa)（見下圖）能夠使用ALPS文檔作為輸入，而[Pivotal](http://pivotal.io/)的[Spring-Data](http://docs.spring.io/spring-data/rest/docs/current/reference/html/#metadata)工具能夠將ALPS文檔的生成作為API構建過程中的一環。  **圖****?6.?****通過****Rapido API****設計器管理檔案的詞匯表** ### 只是一種嘗試，還是將領導新的潮流？ 雖然在Web API中使用檔案的做法重新吸引了人們的注意，但這種技術到底是一種會逐漸消失的實驗？還是會由此開創一個新的趨勢，以專注于獨立地定義Web API的數據與行為語義？現在下判斷還為時過早。 ## 所面臨的挑戰 在本文中，你對于Web API元數據的三個關鍵領域，即描述、發現及檔案有了一個初步的了解。Swagger、RAML以及Apiary等技術目前掌握著主動權，它們控制了API描述這一領域，而在這個發展良好的生態系統中還存在著一些其它技術。有一些工具能夠通過描述格式實現代碼與文檔生成的自動化，并且圍繞著幾個關鍵的格式，出現了許多功能強大的工具集。 API發現這一領域依然由以人類驅動的搜索與選擇方式作為主導，而像Intel的Mashery這種關鍵的API聚合器依然是通過提供一種聚合的方式訂閱遠程的API。而自動化的、基于配置的定位服務也正在逐漸興起，以支持連接到企業級服務實例的功能。其中有部分方式或許將提供對基于互聯網的API進行自動化服務發現的功能。 最后是API檔案，它常用于圖書館與信息科學領域中，而它在與業務相關的Web API領域中也逐漸引起了人們的關注。目前出現的一些首創概念要么還屬于實驗性質，要么很少為人所知，但已經開始有一些API提供商開始支持API檔案了。 Web是一個充滿活力的、飛速發展的領域，為了即時到來的時刻，不妨關注一下API生態系統中的這種“元層面”的思想，這一過程應當是充滿趣味的。 ## 關于作者  **Mike Amundsen**是一位國際知名作者與講師，他經常在全球各地旅行，就分布式網絡架構、Web應用開發以及其它主題進行顧問工作與演講。Amundsen在API Academy擔任架構總監的角色，負責為全球范圍內的公司提供服務，幫助客戶與企業了解如何最好地利用由API帶來的無數機遇。在過去15年間，Amundsen編寫了大量與編程相關的書籍與論文。他目前正在撰寫一本名為《學習客戶端超媒體》的新書，其中涵蓋了構建能夠充分利用超媒體API服務的客戶端應用的常見方式。他最近出版的一本書是與Leonard Richardson合著的《RESTful Web APIs》，于2013年出版。Amundsen在2011年出版的書籍《通過HTML5與Node創建超媒體API》是在構建具有可適應性的Web應用時經常被引用的一本著作。他目前正在為O’Reilly創作一本新書《學習客戶端超媒體》，在2015年秋季應當能夠看到它的身影。 **查看英文原文：**[Description, Discovery, and Profiles: A Primer](http://www.infoq.com/articles/description-discovery-profiles-primer)