程式師世界 >> 編程語言 >> 更多編程語言 >> Rational >> 運用REST API集成及擴展IBM Rational Team Concert

運用REST API集成及擴展IBM Rational Team Concert

編輯：Rational

簡介：從 IBM Rational Team Concert 2.0 開始，REST API 得到了正式地支持（實驗版發布在RTC 1.0.1）。雖然目前 REST API 提供的功能還比較有局限，但對於一般的集成需求已經足夠，而且對於 REST API 的增強在後續版本中會不斷推出。本文將引領讀者了解在 RTC 2.0.0.2 中 REST API 所提供的功能以及相關概念。並且提供了一個 Java 實現的 RTC REST API 客戶端程序供讀者參考。

IBM Rational Team Concert 簡介

IBM Rational Team Concert (RTC) 是構建在 IBM Rational 面向軟件交付技術的下一代協作平台 Jazz 平台上的第一個商用產品、一個協作式的軟件開發環境，它包含了集成的源代碼控制、工作項管理和構建管理等功能。IBM Rational Team Concert 是一個可實時相互協作的軟件交付環境，可以幫助跨地域分布的開發團隊簡化協作開發過程，並使其軟件交付過程實現自動化管理。developerWorks 及網絡上有大量的文章對 RTC 進行介紹，這裡就不再贅述。參考資源部分列出了一些資源供大家學習。截至本文發表 RTC 最新的穩定版是 2.0.0.2，因此，以下所有對於 RTC REST API 的介紹都是基於 2.0.0.2 的。

OSLC-CM 規范

RTC REST API 的實現遵守 OSLC-CM 規范。

什麼是 OSLC？

OSLC 是 Open Service for Lifecycle Collaboration 的縮寫，亦即面向生命周期協作的開放服務。 OSLC 社區的成立旨在幫助軟件實施團隊在合作中簡化生命周期工具的使用。OSLC 社區的使命是創建開放、公開的資源和接口描述用以分享軟件實施團隊所依賴的基礎設施，例如，變更管理、測試用例、缺陷、需求以及用戶故事。倘若所有對生命周期資源和服務的訪問都遵從公共的規范，工具之間傳統的障礙將自然消除從而開啟一扇通向新型協作方式的大門。無論是對於最敏捷的或者是最傳統的項目，OSLC 都能夠為軟件實施團隊以及工具提供商帶來價值，同樣，它也能夠造福於商業工具、開源工具以及內部開發的工具。

什麼是 OSLC-CM？

OSLC-CM 是 OSLC 的一個子集。它的重點在於變更管理（Change Management）。通過 OSLC-CM 你可以查詢、鏈接、獲取、創建以及更新變更請求。

RTC REST API 概述

RTC 1.0 僅提供給用戶 Java API 以集成和擴展 RTC。Java API 包含兩部分：Eclipse 插件 API 和一般 Java API。Eclipse 插件 API 適用於在現有的 RTC Eclipse 客戶端中擴展 RTC 應用而一般 Java API 則適用於普通的 Java 應用程序。在 RTC 1.0.1 中，出現了 REST API，不過是實驗版。在 RTC 2.0 中，RTC 正式開始支持 REST API，目前 REST API 支持的功能還較為有限，但對於一般的集成需求已經足夠，其功能主要集中在對工作項（Work Item）的管理。在後續的版本中，越來越多的功能將會加入到 REST API 中。目前已經有不少軟件在使用 RTC REST API，例如 Mylyn、Rational Quality Manager、 Rational Requirements Composer 以及 Git Integration 等。

關於 REST 的優點，維基百科上是這樣定義的：

可以利用緩存 Cache 來提高響應速度

通訊本身的無狀態性可以讓不同的服務器的處理一系列請求中的不同請求，提高服務器的擴展性

浏覽器即可作為客戶端，簡化軟件需求

相對與其他疊加在 HTTP 協議之上的機制，REST 的軟件依賴性更小

不需要額外的資源發現機制

在軟件技術演進中的長期的兼容性更好

對 RTC 而言，有了 REST API 的支持後，客戶端的程序語言將不再局限於 Java。即便你的應用是一般的 Java 應用，REST API 同樣值得推薦，因為使用 REST API 代碼更加簡潔並且依賴的 Jar 文件比較少（使用 Java API 約需要引入大約 20M 的 Jar 文件，但是使用 REST API 大約只需要引入 3M 左右的 Jar 文件，見本文提供的示例程序）。

簡單來說，RTC REST API 提供了如下功能：

以多種格式（如 JSON、XML、ATOM 以及 HTML）在不同粒度級別上獲取工作項

通過更新 JSON 或者 XML 的方式修改工作項的屬性

通過獲取 HTML 的創建對話框模塊來創建工作項

通過發送帶有 JSON 或者 XML 格式數據的 Post 請求創建工作項

增加或者刪除鏈接

通過全文檢索和指定屬性查詢工作項

通過獲取 HTML 的選擇器模塊查詢工作項

RTC REST API 詳解

下面對 RTC REST API 的功能做更為具體的介紹。

服務發現

RTC 提供了服務發現機制。用戶應當通過該機制獲得需要的服務 URL 而不是將服務 URL 硬編碼在自己的程序中。根服務發現 URL 格式如下：

https://<server>:<port>/<app>/rootservices

實例如：

https://localhost:9443/jazz/rootservices

該 URL 將返回一個 XML 文檔，其中對主要的服務資源入口做了定義。該機制是一個鏈式機制，也就是說，當你獲得了根服務描述文檔後，可以根據其中包含的資源的 URL 進一步獲取子集中的服務 URL。

獲取資源表象

通過如下兩種 URL 格式可以獲取資源表象。

格式一（位置 URI）：

https://<server>:<port>/jazz/resource/itemName/ com.ibm.team.workitem.WorkItem/<resource　identifier>

實例如：

https://localhost:9443/jazz/resource/itemName/ com.ibm.team.workitem.WorkItem/262

以及

https://localhost:9443/jazz/resource/itemOid/ com.ibm.team.workitem.WorkItem/_Kk8YQFElEd6wrL4Qi7w25Q

格式二：

https://<server>:<port>/jazz/oslc/workitems/ <resource　identifier>.<media　type　extension>

實例如：

https://localhost:9443/jazz/oslc/workitems/821.xml

以及

https://localhost:9443/jazz/oslc/workitems/_Kk8YQFElEd6wrL4Qi7w25Q.json

此此格式主要用於開發階段。

除了 .xml 和 .json，其他幾種支持的媒體類型擴展包括：.hover.html，.atom 以及 .xhtml。如若要返回一個資源的多種表象則需要通過指定 HTTP 的 Accept 頭信息或者在 URL 中指定 _mediaType 參數，例如：

https://localhost:9443/jazz/resource/itemName/ com.ibm.team.workitem.WorkItem/821?_mediaType=application/x-oslc-cm-changerequest% 2Bjson

該 URL 將返回工作項 821 的 JSON 格式數據。

獲取資源表象部分屬性

有時我們只需要獲取一個資源部分屬性數據，尤其在移動設備應用中，出於減少帶寬消耗的考慮，我們通常只獲取我們真正需要的數據。通過在 URL 中添加 oslc_cm.properties=propA,propB 可以實現資源部分屬性數據的獲取。例如：

https://localhost:9443/jazz/oslc/workitems/ 821.json?oslc_cm.properties=dc:identifier,dc:title

將僅返回資源的 dc:identifier 和 dc:title 屬性值。

查詢工作項

查詢工作項通過在 https://<host>:<port>/jazz/oslc/contexts/<project area id>/workitems 的後面添加 ?oslc_cm.query=[query] 語句實現。[query] 是一個 CM Query 語句。詳細語法請參見變更管理查詢語法講解。

例如，下面這個查詢是一個編碼過的全文檢索查詢，用來獲取所有包含“NPE”文本的工作項。

https://localhost:9443/jazz/oslc/contexts/_9BHm0EqVEd6HXO10niqZpg/workitems ?oslc_cm.query=oslc_cm%3AsearchTerms%3D%22NPE%22

同樣，你可以通過添加 oslc_cm.properties 語句限制結果返回的屬性值，並且還可以使用“/sort” 指定查詢返回結果的排序方式。分頁查詢也是支持的，例如使用 oslc_cm.pageSize 參數就可以指定查詢結果每頁返回的條目數。

使用預定義的查詢語句

通過形如 https://localhost:9443/jazz/oslc/queries.xml（當然你可以用 queries.json）的 URL 可以獲得所有預定義的查詢語句。增加 oslc_cm.query 參數則可以根據指定的查詢參數過濾返回的查詢語句結果。獲取查詢語句的唯一標識符之後，便可進而通過如下的 URL 獲取該查詢的返回結果。

https://localhost:9443/jazz/oslc/queries/_vS4rsF5eEd6EzYK1TPZjDw/rtc_cm:results.atom

創建工作項

構造並發送包含某種媒體類型（例如 JSON）的工作項表象數據的 POST 請求到形如下的 URL 即可創建一個工作項：

https://localhost:9443/jazz/oslc/contexts/_9BHm0EqVEd6HXO10niqZpg/workitems

其中，_9BHm0EqVEd6HXO10niqZpg 是項目區域唯一標識符。那麼，如何得知媒體類型的具體格式規范呢？當然，你可以通過查看 OSLC-CM 規范獲得。但是，一個更為直觀快捷的方式是你先用那種媒體類型獲得某個工作項的數據，然後查看其格式。例如，你可以通過以下的 URL 返回的數據得知如何定義一個工作項的 JSON 格式表象。

https://localhost:9443/jazz/oslc/workitems/821.json

創建草稿工作項同創建一般的工作項一樣，只需將發送的目標 URL 改為如下：

https://localhost:9443/jazz/oslc/contexts/_9BHm0EqVEd6HXO10niqZpg/drafts/workitems

更新工作項

更新工作項的過程為：首先以某種媒體格式獲取資源數據，接著根據需要對數據進行修改，最後發送 PUT 或者 PATCH 請求。可能會出現在你獲取資源並且提交修期間其他客戶端也修改了該資源的情況，如果沒有采取任何措施，那麼你的提交就會覆蓋先前那個客戶端的修改內容，從而造成數據丟失。為防止此現象的發生，你可以在獲取資源後獲取並保存它的 ETag 屬性值，並在發送 PUT 或者 PATCH 請求的 If -Match 頭信息中設置該 ETag 值。那麼，倘若其他客戶端在期間做了修改，你將會收到 HTTP 響應的 412 返回代碼。此時，你應該重新獲取數據並修改後重新提交。

更新工作項的部分屬性

有時我們需要更新工作項的部分屬性（或許這樣更加安全）。你可以通過以下兩種方式：

方法一：發送 URL 中帶有 oslc_cm.properties 的 PUT 請求

例如，發送 PUT 請求到：

https://localhost:9443/jazz/resource/ itemName/com.ibm.team.workitem.WorkItem/821?oslc_cm.properties=dc:type

無論發送的數據中包含多少更改，都只更新 dc:type 屬性。

方法二：發送 PATCH 請求

例如，發送僅包含 dc:type 屬性的數據的 PATCH 請求到：

https://localhost:9443/jazz/oslc/workitems/821

也將只更改其 dc:type 屬性。

增加 / 刪除鏈接

通過在發送的工作項表象數據中包含鏈接更新整個工作項是一增加鏈接的方式，除此以外，你還可以采用發送包含如下的 JSON 或者 XML 數據的 POST 請求到形如：

https://localhost:9443/jazz/oslc/workitems/ 821/oslc_cm:relatedChangeManagement

的 URL 的方式。

XML：

<oslc_cm:relatedChangeManagement rdf:resource="https://example.org/changerequests/10253"　oslc_cm:label="Task　 10253"/>

JSON：

{ 　 "rdf:resource":"https:\/\/example.org\/changerequests\/10253", 　 "oslc_cm:label":"Task　10253" }

如需增加多條鏈接，只需在 JSON 或 XML 數據中增加多項即可。

刪除鏈接如同增加鏈接一樣：從數據中刪除鏈接後，發送 PUT 或者 PATCH 請求更新工作項。

增加備注

發送帶有如下數據的 POST 請求到形如 https://localhost:9443/jazz/oslc/workitems/821/rtc_cm:comments 的 URL 可以為工作項增加備注。

{ 　 "dc:description":"My　new　comment" }

上面的例子是 JSON 數據。當然，你也可以采用其他的媒體類型。

RTC REST API 客戶端示例程序介紹

通常，為了方便其他程序模塊對 REST API 的調用，我們都會將其封裝。這樣的程序模塊叫做 REST API 客戶端。本文提供了一個 Java 實現的 REST API 客戶端示例程序供用戶參考。當然，該示例程序純粹用於向讀者示范 RTC REST API 的使用，所以它對 RTC REST API 封裝的並不完整並且可能存有缺陷，為了簡單起見，其中資源 URL 也並非從 RTC 服務發現功能中獲取。因此，讀者若真要在自己的環境中使用，仍需要進一步修改和完善它。該示例程序簡單的封裝了對 RTC REST API 的調用，並實現了如下步驟的測試用例：

創建一個標題為“Sample title”的缺陷

通過缺陷的 ID 獲取該新創建的缺陷

修改缺陷的嚴重性以及標題值

為缺陷增加備注

將缺陷的狀態從 New 改為 Resolved 再改為 Closed

通過缺陷的狀態及標題查詢出該缺陷

開發環境的搭建

下載代碼包 RTCRestClient_sample.zip，（參見下載）並直接作為已有項目導入到工作區。出於種種考慮，本文附帶的代碼包並未包含依賴的 Jar 文件，因此你會發現項目有編譯錯誤，所以接下來你需要自己下載依賴的 Jar 文件並手動添加到項目構建路徑當中。

圖 1. 導入示例項目

以下是該示例程序依賴的開源項目：

HttpClient 4.0.1：用來發送處理 HTTP 請求以調用 RTC REST API。

Json-lib 2.3 ：示例程序中選用了 JSON 的發送 / 返回數據格式。Json-lib 用來封裝發送及返回的數據。

Log4j-1.2.12：用來輸出日志。

若干 Apache Commons 項目：這些都是 HttpClient 以及 Json-lib 依賴的庫文件。

以下是你需要下載及導入的 Jar 文件：

apache-mime4j-0.6.jar

commons-beanutils-1.8.3.jar

commons-codec-1.3.jar

commons-collections-3.2.1.jar

httpclient-4.0.1.jar

httpcore-4.0.1.jar

httpmime-4.0.1.jar

commons-lang-2.5.jar

commons-logging-1.1.1.jar

ezmorph-1.0.6.jar

json-lib-2.3-jdk15.jar

log4j-1.2.12.jar

你可以從以下網站獲得上面的 Jar 文件：

http://json-lib.sourceforge.net/

http://commons.apache.org/

http://hc.apache.org/

http://logging.apache.org/log4j/1.2/

http://ezmorph.sourceforge.net/

運行示例程序

如果項目能夠正常編譯之後，你就可以開始運行示例程序。下面是運行該示例程序的步驟：

步驟一：在 config.properties 中設置你的 RTC 的用戶名，密碼，RTC 基本 URL 以及項目區域名稱。

清單 1. config.properties 設置

#　RTC　account　id,　e.g　[email protected] [email protected] #　RTC　account　password password= #　RTC　base　URL,　e.g.　https://<host>:<port>/jazz rtc.base.url= #　Project　Area　name,　e.g.　Mashup　Center projectarea.name=Mashup　Center

步驟二：運行 SampleCaller.java。由於示例程序中使用 JVM 的斷言語句，所以，請在運行配置中添加 JVM 參數“-ea”以啟用 JVM 的斷言功能。

圖 2. 示例程序運行設置

如果一些正常，Eclipse 控制台將顯示如下類似信息。

清單 2. 控制台輸出示例

2010-06-03　13:33:37　[com.ibm.rtc.restclient.SampleCaller]-[INFO] 　　 14789　was　created　successfully.　-(:40) 2010-06-03　13:33:44　[com.ibm.rtc.restclient.SampleCaller]-[INFO] 　　 14789　was　retrived　successfully.　-(:47) 2010-06-03　13:34:01　[com.ibm.rtc.restclient.SampleCaller]-[INFO] 　　 14789　was　updated　successfully.　-(:59) 2010-06-03　13:34:20　[com.ibm.rtc.restclient.SampleCaller]-[INFO] 　　 14789　was　closed　successfully.　-(:72) 2010-06-03　13:34:31　[com.ibm.rtc.restclient.SampleCaller]-[INFO] 　　 14789　was　searched　successfully.　-(:84)

示例程序源代碼解析

打開包管理器，所有類如下圖所示。

圖 3. 源代碼包結構

下面對每個類的功能進行簡單地介紹。

RTCRestClientException.java該類作為該項目的根 Exception 類。Resource.java該類封裝了 RTC 中常規資源的屬性：包含資源的名稱、類型以及對應的資源 URL。比如工作項中的 Severity、Priority 以及 State 等都是一個資源對象實例。Workitem.java該類對 RTC 中的工作項進行了封裝。一個工作項中通常包含唯一標識符、標題、描述、Severity、Priority 等屬性。該類也包含了同 JSON 對象之間相互轉換的方法。Configuration.java該類用於讀取系統配置文件 config.properties。 QueryResults.java該類用以封裝 REST API 的查詢結果。RTCRestClient.java該類封裝了對 RTC REST API 調用，以傳統的 Java 方法暴露對 RTC 的操作。對於每次 REST API 操作，程序會檢查是否已進行過認證或者之前認證後獲取的 Cookie 是否仍有效或者已過期。如果 Cookie 已過期則重新認證。本示例代碼實現是表單認證方式，如果你的 RTC 配置的是基本認證方式則需要自己對代碼做些修改。 WorkitemManager.java該類通過對 RTCRestClient.java 的調用封裝了若干對工作項的操作，例如創建工作項、查詢工作項、修改工作項狀態等操作。SampleCaller.java該類是一個示例客戶端調用程序。它調用了 WorkitemManager 中的方法並輸出運行結果。

創建工作項代碼詳解

圖 4. UML 時序圖（創建工作項）

從上面的時序圖中，讀者可以清楚地了解代碼之間的調用關系。下面是相關的代碼片斷。

清單 3. SampleCaller.java

Workitem　wi=new　Workitem(); wi.setTitle(title); wi.setDescription("Sample　description"); wi.setFiledAgainst(new　Resource(Resource.RES_TYPE_FILEDAGAINST,"MM　V2.4")); wi.setFoundIn(new　Resource(Resource.RES_TYPE_FOUNDIN,"2.4/CSA2")); wi.setSeverity(new　Resource(Resource.RES_TYPE_SEVERITY,"Sev4")); wi.setPriority(new　Resource(Resource.RES_TYPE_PRIORITY,"Low")); wi.setOwnedBy(RTCRestClient.getInstance().getUser("[email protected]")); wi.setType(new　Resource(Resource.RES_TYPE_TYPE,"Defect")); wi=manager.createWorkitem(wi);

首先，創建一個 Workitem 實例，然後構造並設置需要的屬性，之後調用 WorkitemManager.java 的 createWorkitem 方法創建工作項。

清單 4. WorkitemManager.java

public　Workitem　createWorkitem(Workitem　workitem){ 　　 JSON　jsonObject=client.post(projectAreaWorkitemsUrl,　workitem.toJSONString ()); 　　 return　Workitem.fromJSON((JSONObject)　jsonObject); }

createWorkitem 方法調用 RTCRestClient.java 的 post 方法發送 POST 請求以創建 Workitem，之後並調用 Workitem.java 的 fromJSON 方法將返回的字符串構造成一個 Workitem 實例作為方法返回值。

清單 5. RTCRestClient.java

public　JSON　post(String　url,　String　requestContent)　{ 　　　　 return　jsonHttp(url,　HTTP_METHOD_POST,　requestContent); 　　 } private　JSON　jsonHttp(String　url,　int　httpType,　String　requestContent)　{ try　{ 　　 authenticate(); 　　 DefaultHttpClient　httpClient　=　new　DefaultHttpClient(); 　　 httpClient.getCookieStore().addCookie(cookie); 　　 HttpRequestBase　httpMethod　=　null; 　　 switch　(httpType)　{ 　　　　 case　HTTP_METHOD_GET: 　　　　　　 httpMethod　=　new　HttpGet(url); 　　　　　　 break; 　　　　 case　HTTP_METHOD_POST: 　　　　　　 httpMethod　=　new　HttpPost(url); 　　　　　　 break; 　　　　 case　HTTP_METHOD_PUT: 　　　　　　 httpMethod　=　new　HttpPut(url); 　　　　　　 break; 　　　　 } 　　　　 httpMethod.addHeader("Content-Type","application/x-oslc-cm-change- request+json"); 　　　　 httpMethod.addHeader("Accept",　"text/json"); 　　　　 if　(httpType　==　HTTP_METHOD_POST　||　httpType　==　HTTP_METHOD_PUT)　{ 　　　　　　 StringEntity　requestEntity　=　new　StringEntity(requestContent); 　　　　　　　　 ((HttpEntityEnclosingRequestBase)　httpMethod) 　　　　　　　　　　　　 .setEntity(requestEntity); 　　　　 } 　　　　 HttpResponse　response　=　httpClient.execute(httpMethod); 　　　　 String　rtJson　=　convertStreamToString(response.getEntity() 　　　　　　　　　　 .getContent()); 　　　　 httpClient.getConnectionManager().shutdown(); 　　　　 return　JSONSerializer.toJSON(rtJson); 　　 }　catch　(IOException　e)　{ 　　　　 e.printStackTrace(); 　　 } 　　 return　null; }

jsonHttp 對各種類型的 HTTP 請求進行了封裝並將返回值構造成 JSON 對象。而 post，get 以及 put 方法都調用 jsonHttp 方法實現真正的 HTTP 請求操作，只是傳入了不同的 HTTP 請求類型字符串 httpType。HTTP_METHOD_GET，HTTP_METHOD_POST 以及 HTTP_METHOD_PUT 是三個字符串靜態常量，用來代表不同的 HTTP 請求類型。

清單 6. Workitem.java

public　static　Workitem　fromJSON(JSONObject　jsonObject)　{ 　　 DynaBean　bean　=　(DynaBean)　JSONSerializer.toJava(jsonObject); 　　 Workitem　workitem=new　Workitem(); 　　 workitem.setIdentifier(((Integer)　bean.get("dc:identifier")).intValue()); 　　 workitem.setTitle((String)　bean.get("dc:title")); 　　 workitem.setDescription((String)　bean.get("dc:description")); 　　 workitem.setType(createResource(bean,"dc:type",Resource.RES_TYPE_TYPE)); 　　 workitem.setOwnedBy(createResource(bean,"rtc_cm:ownedBy", 　　　　 Resource.RES_TYPE_USER)); 　　 workitem.setFoundIn(createResource(bean,"rtc_cm:foundIn", 　　　　 Resource.RES_TYPE_FOUNDIN)); 　　 workitem.setFiledAgainst(createResource(bean,"rtc_cm:filedAgainst", 　　　　 Resource.RES_TYPE_FILEDAGAINST)); 　　 workitem.setSeverity(createResource(bean,"oslc_cm:severity", 　　　　 Resource.RES_TYPE_SEVERITY)); 　　 workitem.setPriority(createResource(bean,"oslc_cm:priority", 　　　　 Resource.RES_TYPE_PRIORITY)); 　　 workitem.setState(createResource(bean,"rtc_cm:state",Resource.RES_TYPE_STATE)); 　　 return　workitem; }

fromJSON 方法能夠將 JSONObject 對象轉換成一個 Workitem 實例。

更新工作項代碼詳解

圖 5. UML 時序圖（創建工作項）

更新工作項的過程比創建工作項的過程稍微復雜一些。下面是相關的代碼片斷。

清單 7. SampleCaller.java

/* *　Get　the　workitem */ wi=manager.getWorkitemById(wi.getIdentifier()); assert　wi.getIdentifier()==workitemId; logger.info(wi.getIdentifier()+"　was　retrived　successfully."); /* *　Change　its　severity */ Resource　severity=wi.getSeverity(); severity.setTitle("Sev3"); wi.setSeverity(severity); wi.setTitle(newTitle); wi=manager.updateWorkitem(wi); assert　"Sev3".equals(wi.getSeverity().getTitle()); assert　newTitle.equals(wi.getTitle()); logger.info(wi.getIdentifier()+"　was　updated　successfully.");

SampleCaller 首先通過唯一標識符調用 WorkitemManager.java 的 getWorkitemById 方法獲取 Workitem 實例，然後修改 Workitem 實例的屬性值，最後調用 WorkitemManager.java 的 updateWorkitem 方法更新 Workitem 實例。

清單 8. WorkitemManager.java

public　Workitem　updateWorkitem(Workitem　workitem){ 　　 String　url=workitemsUrl+"/"+workitem.getIdentifier(); 　　 JSON　jsonObject=client.put(url,　workitem.toJSONString()); 　　 return　Workitem.fromJSON((JSONObject)　jsonObject); } public　Workitem　getWorkitemById(int　id){ 　　 String　url=workitemsUrl+"/"+id; 　　 return　Workitem.fromJSON((JSONObject)　client.get(url)); }　

WorkitemManager.java 調用 RTCRestCient.java 的 put 方法更新 Workitem 數據，其中的 workitemsUrl 在 WorkitemManager.java 的構造函數被初始化，代碼如下：

清單 9. WorkitemManager.java 構造函數

private　WorkitemManager(){ 　　 client=RTCRestClient.getInstance(); 　　 String　projectAreaId=client.getProjectAreaId(); 　　 String　rtcBaseUrl=client.getRtcBaseURL(); 　　 projectAreaWorkitemsUrl=　rtcBaseUrl　+　"/oslc/contexts/" 　　　　 +　projectAreaId　+　"/workitems"; 　　 workitemsUrl=　rtcBaseUrl　+　"/oslc/workitems"; }　

workitemUrl 理論上應當通過服務發現機制獲得，這裡只是從簡單實現角度出發，所以采用了字符串拼接的方法。

清單 10. RTCRestClient.java

public　JSON　get(String　url)　{ 　　 return　jsonHttp(url,　HTTP_METHOD_GET,　null); } public　JSON　put(String　url,　String　requestContent)　{ 　　 return　jsonHttp(url,　HTTP_METHOD_PUT,　requestContent); }

如“創建工作項詳解”部分所述：get 和 put 方法都調用 jsonHttp 方法實現真正的 HTTP 請求操作的。

值得一提的是目前無法通過像修改工作項的其他屬性那樣的方式修改工作項的狀態，而需要發送帶有 _action 參數的 PUT 請求實現。例如，要關閉一個工作項，那麼需要發送 PUT 請求到

https://localhost:9443/jazz/oslc/workitems/821? _action=bugzillaWorkflow.action.close

不過，action 字符串是可以配置的，因此本示例中的這個 action 字符串未必可以適用於你的 RTC，所以關於該 action 字符串請聯系你的 RTC 管理員。如果你需要你在關閉工作項的同時又修改某些工作項屬性，可以在發送的 PUT 請求中數據中包含修改後的屬性值（當然，你需要把它構造成 JSON，XML 或者其他支持的媒體類型）。如果你不需要修改任何屬性，就在 PUT 請求中包含唯一標識符。你可以在 WorkitemManager.java 的 changeState 方法中找到相關的代碼。

另外，通過 RTCRestClient.java 的 getResUrlByTitle 方法，對於所有的資源，你只需要指定名稱就可以獲得資源對應的 URL 後構造出 Resource 實例。但是不幸地是在目前的版本中，你無法通過用戶的名稱查詢出對應的資源 URL（會出現一個 dc:title 無法被識別的錯誤信息），所以該示例程序實現了 getUser(String userId) 方法從而通過用戶唯一標識符獲取對應的用戶實例。

結束語

本文對涉及 RTC REST API 的相關概念以及其提供的功能做了介紹。但是限於篇幅原因，有些內容並未展開（例如，OSLC-CM 查詢語法），所以建議讀者在閱讀完本文後對於未展開講解的部分自己學習。另外，本文雖然附有 RTC REST API 客戶端的示例代碼，但是它僅僅為讀者提供參考，所以，無論從功能的完整性以及整體程序架構上說，它都很不完善。讀者如果需要在自己的程序中集成 RTC，仍需要在參考示范代碼的基礎上進一步修改和完善。

原文地址：http://www.ibm.com/developerworks/cn/rational/r-cn-rtc2restapi/index.html

相關下載：

試用版: IBM Rational Team Concert Standard Edition V2

http://www.ibm.com/developerworks/cn/downloads/r/rtc/learn.html

免費版：IBM Rational Team Concert Express-C Edition V2

http://www.ibm.com/developerworks/cn/downloads/r/rtcexpressc/learn.html

IBM Rational 工具包系列

http://www.ibm.com/developerworks/cn/rational/kits/

本文配套源碼