本申請要求2014年11月25日遞交的發(fā)明名稱為“處理通知信道斷連的方法(MethodofHandlingNotificationChannelDisconnection)”的第14/553,545號美國非臨時專利申請案的在先申請優(yōu)先權(quán)，該在先申請的內(nèi)容以引入的方式并入本文本中。
背景技術(shù)：
：：表征狀態(tài)轉(zhuǎn)移(representationalstatetransfer，REST)是萬維網(wǎng)架構(gòu)的一種抽象。更準(zhǔn)確地說，REST是一種架構(gòu)風(fēng)格，其包括應(yīng)用到分布式超媒體系統(tǒng)內(nèi)的組件、連接器和數(shù)據(jù)元的一組協(xié)調(diào)的架構(gòu)約束。REST忽略組件實施和協(xié)議語法的細(xì)節(jié)，以便專注于組件的作用、對這些組件與其它組件的交互的約束、這些組件對重要數(shù)據(jù)元的解釋。REST架構(gòu)風(fēng)格可作為簡單對象訪問協(xié)議(SimpleObjectAccessprotocol，SOAP)等其它分布式計算規(guī)范的備選應(yīng)用于網(wǎng)絡(luò)服務(wù)開發(fā)。如果網(wǎng)絡(luò)服務(wù)遵從涉及或關(guān)于客戶端—服務(wù)器模型、無狀態(tài)協(xié)議、網(wǎng)絡(luò)緩存、分層系統(tǒng)、按需代碼(可選)和統(tǒng)一接口的某些架構(gòu)約束，則可以將這些網(wǎng)絡(luò)服務(wù)描述為“RESTful”。在一些情況下，REST架構(gòu)風(fēng)格可應(yīng)用于網(wǎng)絡(luò)應(yīng)用編程接口(applicationprogramminginterface，API)。遵守架構(gòu)約束的網(wǎng)絡(luò)API稱為RESTful。技術(shù)實現(xiàn)要素：在一項實施例中，本發(fā)明包括一種處理通知信道斷連的方法，所述方法包括：檢測與REST客戶端對應(yīng)的通知信道的斷連，向應(yīng)用服務(wù)器發(fā)送表明所述通知信道斷連的斷連請求，以及從所述應(yīng)用服務(wù)器接收表明所述REST客戶端的訂閱已刪除的響應(yīng)。在另一項實施例中，本發(fā)明包括一種處理通知信道斷連的方法，所述方法包括：從通知服務(wù)器接收表明所述通知服務(wù)器與REST客戶端之間的通知信道斷連的斷連請求，以及向所述通知服務(wù)器發(fā)送表明所述REST客戶端的訂閱已刪除的響應(yīng)。在又一項實施例中，本發(fā)明包括一種通知服務(wù)器，所述通知服務(wù)器包括可操作地耦合到存儲器的處理器，以及存儲在所述存儲器中的通知信道斷連模塊，所述通知信道斷連模塊在由所述處理器執(zhí)行時用于：檢測與REST客戶端對應(yīng)的通知信道斷連，向應(yīng)用服務(wù)器發(fā)送表明所述通知信道斷連的斷連請求，以及從所述應(yīng)用服務(wù)器接收表明所述REST客戶端的訂閱已刪除的響應(yīng)。結(jié)合附圖和權(quán)利要求書可以從以下的詳細(xì)描述中更清楚地理解這些和其它特征。附圖說明為了更透徹地理解本發(fā)明，現(xiàn)參閱結(jié)合附圖和具體實施方式而描述的以下簡要說明，其中的相同參考標(biāo)號表示相同部分。圖1為在RESTful環(huán)境中創(chuàng)建和刪除通知信道和訂閱的方法的協(xié)議圖。圖2為通知信道斷連方法的一實施例的協(xié)議圖。圖3為能夠促進(jìn)圖3的方法的計算設(shè)備的一實施例的示意圖。圖4為處理通知信道斷連的方法的一實施例的流程圖。圖5為處理通知信道斷連的方法的一實施例的流程圖。具體實施方式首先應(yīng)理解，盡管下文提供一項或多項實施例的說明性實施方案，但所公開的系統(tǒng)和/或方法可使用任何數(shù)目的技術(shù)來實施，無論該技術(shù)是當(dāng)前已知還是現(xiàn)有的。本發(fā)明決不應(yīng)限于下文所說明的說明性實施方案、附圖和技術(shù)，包括本文所說明并描述的示例性設(shè)計和實施方案，而是可在所附權(quán)利要求書的范圍以及其等效物的完整范圍內(nèi)修改。本文公開了處理通知信道斷連的各種實施例。如將在下文更充分說明的一樣，本文公開的系統(tǒng)和方法允許通知服務(wù)器在通知信道已斷連時通知應(yīng)用服務(wù)器。因為應(yīng)用服務(wù)器的通知信道當(dāng)前狀態(tài)保持最新，所以在通知信道斷連時，與通知信道綁定的任何訂閱均可由應(yīng)用服務(wù)器刪除。圖1為在RESTful環(huán)境中創(chuàng)建和刪除通知信道和訂閱的方法100的協(xié)議圖。在2013年7月30日發(fā)布的“通知信道的RESTful網(wǎng)絡(luò)API，候選版本1.0(RESTfulNetworkAPIforNotificationChannel,CandidateVersion1.0)”規(guī)范中更詳細(xì)地描述了使用REST架構(gòu)和API創(chuàng)建、刪除和使用通知信道，該規(guī)范的全部內(nèi)容以引入的方式并入本文本中。圖1的方法100在計算設(shè)備的上下文中說明，為方便起見，計算設(shè)備在本文中將稱為客戶端102、通知服務(wù)器104、API服務(wù)器106和核心服務(wù)器108?？蛻舳?02可為個人計算機(personalcomputer，PC)、移動設(shè)備(例如智能手機、平板電腦等等)。每個客戶端102包括用于處理網(wǎng)絡(luò)應(yīng)用的一個或多個API。舉例來說，網(wǎng)絡(luò)應(yīng)用可以是用于進(jìn)行視頻通話的網(wǎng)絡(luò)應(yīng)用(例如MicrosoftSkypeTM)或者用于促進(jìn)客戶端102之間的通信的網(wǎng)絡(luò)應(yīng)用。每個客戶端102包括一個瀏覽器(例如MozillaGoogleMicrosoftInternet或Apple)。如本領(lǐng)域公知的一樣，瀏覽器是一種用于在萬維網(wǎng)上獲取、提供和遍歷信息資源的軟件應(yīng)用。一些網(wǎng)絡(luò)瀏覽器利用一種稱為網(wǎng)頁實時通信(webreal-timecommunications，WebRTC)的技術(shù)。WebRTC是一種由萬維網(wǎng)聯(lián)盟(WorldwideWebConsortium，W3C)起草的API，該API支持瀏覽器到瀏覽器應(yīng)用以進(jìn)行視頻通話、視頻聊天、端對端(peer-to-peer，P2P)文件共享等，無需瀏覽器中的插件。如果客戶端102的瀏覽器包括對WebRTC的支持時，則客戶端102可參與瀏覽器到瀏覽器通信，無需插件。如圖1所示，客戶端102用于與通知服務(wù)器104和API服務(wù)器106進(jìn)行通信。在一項實施例中，API服務(wù)器106是融合通信套件(RichCommunicationSuite，RCS)API服務(wù)器。在一些實施例中，通知服務(wù)器104和API服務(wù)器106之一是或者兩者都是WebRTC用戶網(wǎng)絡(luò)接口(usernetworkinterface，UNI)服務(wù)器。API服務(wù)器106用于與核心服務(wù)器108進(jìn)行通信。在一項實施例中，核心服務(wù)器108是互聯(lián)網(wǎng)協(xié)議(InternetProtocol，IP)多媒體子系統(tǒng)或IP多媒體核心網(wǎng)子系統(tǒng)(IPMultimediaCoreNetworkSubsystem，IMS)。如圖1所示，當(dāng)(例如，運行應(yīng)用的)客戶端102向通知服務(wù)器104發(fā)送通知信道請求時，通知信道開始創(chuàng)建。在一些實施例中，該通知信道請求的格式是超文本傳輸協(xié)議(HypertextTransferProtocol，HTTP)。例如，可使用如2014年2月6日發(fā)布的Internet工程任務(wù)組(InternetEngineeringTaskForce，IETF)文件，超文本傳輸協(xié)議(HTTP/1.1)：語義與內(nèi)容，draft-ietf-httpbis-p2-semantics-26，以及2014年6月發(fā)布的請求注解(RequestforComments，RFC)文件，超文本傳輸協(xié)議(HTTP/1.1)：語義與內(nèi)容，RFC7231中描述的HTTPPOST操作來實施通知信道請求，這兩個文件的全部內(nèi)容以引入的方式并入本文本中。在接收到通知信道請求時，通知服務(wù)器104創(chuàng)建通知信道。然后，通知服務(wù)器104向客戶端102發(fā)回響應(yīng)以告知客戶端102通知信道已建立。在一些實施例中，返回給客戶端102的響應(yīng)包括信道信息，諸如信道數(shù)據(jù)、回調(diào)統(tǒng)一資源定位符(uniformresourcelocator，URL)和信道URL。然后，客戶端102向API服務(wù)器106發(fā)送訂閱請求。訂閱請求可以是例如聊天通知訂閱、文件傳輸通知訂閱等等。訂閱請求包括例如回調(diào)URL。在一些實施例中，訂閱請求的格式是HTTP。例如，可使用HTTPPOST操作來實施訂閱請求。在接收到訂閱請求時，API服務(wù)器106創(chuàng)建訂閱。然后，API服務(wù)器106向客戶端102返回響應(yīng)以告知客戶端102訂閱已建立。返回給客戶端102的響應(yīng)可包括資源URL。在一些實施例中，客戶端102和通知服務(wù)器104用于利用HTTP長輪詢(例如，長輪詢協(xié)議)，使得在客戶端102與通知服務(wù)器104之間存在“心跳”。換言之，通知服務(wù)器104與客戶端102之間存在連續(xù)雙向通信。在一些實施例中，建立其它雙向通信，例如基于同步HTTP的雙向流(Bidirectional-streamsOverSynchronousHTTP，BOSH)、異步JavaScript+可擴展標(biāo)記語言(ExtensibleMarkupLanguage，XML)(asynchronousJavaScript+XML，AJAX)，等等。為了啟動長輪詢過程，客戶端102向通知服務(wù)器104發(fā)送長輪詢請求。該長輪詢請求包括例如信道URL。在一些實施例中，長輪詢請求的格式是HTTP。例如，可使用HTTPPOST操作來實施長輪詢請求。在接收到長輪詢請求時，通知服務(wù)器104向客戶端102發(fā)回響應(yīng)以告知客戶端102長輪詢已建立?？蛻舳?02發(fā)起新的長輪詢請求以便獲得后續(xù)事件。如果例如長輪詢請求在一個完整響應(yīng)被發(fā)送到客戶端102之前超時，則通知服務(wù)器104可向客戶端102發(fā)回超時響應(yīng)。這種情況可能在例如通知服務(wù)器104花太長時間來響應(yīng)來自客戶端102的信息或數(shù)據(jù)請求時發(fā)生。在接收到超時響應(yīng)后，客戶端102可立即進(jìn)行另一個長輪詢請求以保持客戶端102與通知服務(wù)器104之間的通信是激活的或開啟的。仍然參見圖1，當(dāng)API服務(wù)器106從核心服務(wù)器108接收事件通知時，API服務(wù)器106向通知服務(wù)器104發(fā)送該事件通知。當(dāng)通知服務(wù)器104從客戶端102接收下一長輪詢請求時，通知服務(wù)器104在發(fā)往客戶端102的長輪詢響應(yīng)中包括事件信息。例如，通知服務(wù)器通過該響應(yīng)向客戶端102發(fā)送包括事件的通知列表。當(dāng)客戶端102需要刪除通知信道時，該客戶端向通知服務(wù)器發(fā)送刪除通知信道請求。在一些實施例中，刪除通知信道請求的格式是HTTP。例如，可使用2014年2月6日發(fā)布的IETF文件，超文本傳輸協(xié)議(HTTP/1.1)：語義與內(nèi)容，draft-ietf-httpbis-p2-semantics-26，以及2014年6月發(fā)布的RFC文件，超文本傳輸協(xié)議(HTTP/1.1)：語義與內(nèi)容，RFC7231中描述的HTTPDELETE操作來實施刪除通知信道請求，這兩個文件的全部內(nèi)容以引入的方式并入本文本中。在接收到刪除通知信道請求時，通知服務(wù)器104刪除通知信道。然后，通知服務(wù)器104向客戶端102發(fā)回響應(yīng)以告知客戶端102通知信道已刪除。然后，客戶端102向API服務(wù)器106發(fā)送訂閱刪除請求。在一些實施例中，訂閱刪除請求的格式是HTTP。例如，可使用HTTPDELETE操作來實施訂閱刪除請求。在接收到訂閱刪除請求時，API服務(wù)器106刪除訂閱。然后，API服務(wù)器106向客戶端102返回響應(yīng)以告知客戶端102訂閱已刪除。但是，上述創(chuàng)建和刪除通知信道和訂閱的過程沒有定義任何在通知信道斷連時的處理。事實上，通知服務(wù)器104檢測到通知服務(wù)器104與客戶端102之間的通知信道已中斷，通知服務(wù)器104無法通知API服務(wù)器106。因此，API服務(wù)器106無法刪除訂閱。圖2為解決前述問題的通知信道斷連方法200的一實施例的協(xié)議圖。方法200在通知信道臨時或永久斷連或者中斷時使用。方法200使用(例如，運行應(yīng)用的)客戶端202、通知服務(wù)器204和API服務(wù)器206實施。在一些實施例中，客戶端202、通知服務(wù)器204和API服務(wù)器206與圖1中的客戶端102、通知服務(wù)器104和API服務(wù)器106類似配置。圖2所示的創(chuàng)建通知信道、請求訂閱和在客戶端202與通知服務(wù)器204之間建立長輪詢的過程與結(jié)合圖1描述的那些過程相似或相同。為簡單起見，本文有意不重復(fù)這些過程的完整描述。在客戶端202與通知服務(wù)器204之間的長輪詢已建立后，如圖2所示，通知信道可能非期望地斷連。如果發(fā)生這種情況，客戶端202向通知服務(wù)器204發(fā)送的任何長輪詢通信都將失敗，如圖2中輪詢請求上的“X”所示。通知服務(wù)器204能夠檢測到通知信道的故障或斷連。在一些實施例中，通知服務(wù)器204在長輪詢過程的“心跳”不再能感覺到或已停止時，確定通知信道已發(fā)生故障。在一些實施例中，如果通知服務(wù)器204在預(yù)定時間內(nèi)沒有從客戶端202接收到通信，則確定通知信道斷連。在已檢測到通知信道斷連時，通知服務(wù)器204向API服務(wù)器206發(fā)送斷連請求。該請求向API服務(wù)器206表明客戶端202與通知服務(wù)器204之間的通知信道斷連。在一些實施例中，斷連請求包括回調(diào)URL和在客戶端202上運行的應(yīng)用的用戶標(biāo)識(例如，用戶ID)。在一些實施例中，斷連請求的格式是HTTP。例如，可使用HTTPPOST操作來實施斷連請求。在接收到斷連請求時，API服務(wù)器206刪除與客戶端202對應(yīng)的訂閱。例如，API服務(wù)器206根據(jù)從通知服務(wù)器204接收的用戶ID和回調(diào)URL刪除訂閱。然后，API服務(wù)器206向通知服務(wù)器204發(fā)回響應(yīng)。該響應(yīng)表明關(guān)于客戶端202的訂閱(例如，與用戶ID和/或回調(diào)URL對應(yīng)的訂閱)已刪除。通過在客戶端202與通知服務(wù)器204之間的通知信道已斷連時刪除客戶端202的訂閱，避免了服務(wù)通知的無效訂閱。換言之，去除了無效資源。圖3為用于通過圖1至圖2所示的系統(tǒng)的至少一部分發(fā)送和接收消息或信息的服務(wù)器300的一實施例的示意圖。本發(fā)明中描述的至少一些特征/方法可在服務(wù)器300中實施。例如，本發(fā)明的特征/方法可在硬件、固件和/或安裝以運行于該硬件上的軟件中實施。服務(wù)器300可為通過網(wǎng)絡(luò)、系統(tǒng)和/或域傳輸數(shù)據(jù)的任意設(shè)備。此外，術(shù)語服務(wù)器、計算機、邏輯設(shè)備和/或類似術(shù)語可互換地使用以概括性地描述服務(wù)器并且沒有特定或特殊意義，除非本發(fā)明內(nèi)另有特殊說明和/或要求。在一項實施例中，服務(wù)器300可為用于參與圖2所示的通知信道斷連處理的裝置。另外，服務(wù)器300的組件或功能可實施和/或集成在如圖1至圖2所描述和示出的客戶端202、通知服務(wù)器204、API服務(wù)器206或核心網(wǎng)108中的設(shè)備中。服務(wù)器300可包括耦合到收發(fā)器(transceiver，Tx/Rx)320的一個或多個下游端口310，收發(fā)器320可以是發(fā)射器、接收器或其組合。Tx/Rx320可通過下游端口310傳輸和/或接收來自其它網(wǎng)絡(luò)設(shè)備(例如服務(wù)器等)的消息或信息。類似地，服務(wù)器300可包括耦合到多個上游端口340的另一Tx/Rx320，其中Tx/Rx320可通過上游端口340傳輸和/或接收來自其它網(wǎng)絡(luò)設(shè)備的消息或信息。下游端口310和/或上游端口340可包括電和/或光傳輸和/或接收組件。處理器330可耦合到Tx/Rx320，并可用于處理消息或信息和/或確定向哪些服務(wù)器發(fā)送(例如傳輸)消息或信息。在一實施例中，處理器330可包括一個或多個多核處理器和/或存儲器模塊350，其可用作數(shù)據(jù)存儲器、緩沖器等。處理器330可實施為通用處理器或可為一個或多個專用集成電路(applicationspecificintegratedcircuit，ASIC)、現(xiàn)場可編程門陣列(field-programmablegatearray，F(xiàn)PGA)和/或數(shù)字信號處理器(digitalsignalprocessor，DSP)的一部分。盡管示為單個處理器，但處理器330不限于此并可包括多個處理器。處理器330可用于本文所述的媒體資源的自適應(yīng)且動態(tài)的分配。圖3示出了存儲器350可耦合至處理器330并且可以是用于存儲各種類型的數(shù)據(jù)的非瞬時性介質(zhì)。存儲器350可包括存儲器設(shè)備，包括輔助存儲器、只讀存儲器(read-onlymemory，ROM)和隨機存取存儲器(random-accessmemory，RAM)。輔助存儲器通常包括一個或多個磁盤驅(qū)動器、光驅(qū)、固態(tài)驅(qū)動器(solid-statedrives，SSD)和/或磁帶驅(qū)動器，并且用于數(shù)據(jù)的非易失性存儲，而且如果RAM的容量不足以存儲所有工作數(shù)據(jù)，輔助存儲器則用作溢流數(shù)據(jù)存儲設(shè)備。輔助存儲器可用于當(dāng)加載到RAM中程序被選擇執(zhí)行時存儲這類程序。ROM用于存儲指令，可能還存儲在程序執(zhí)行期間讀取的數(shù)據(jù)。ROM是非易失性存儲器設(shè)備，通常具有相對于輔助存儲器的大存儲容量來說較小的內(nèi)存容量。RAM用于存儲以易失性數(shù)據(jù)，可能還存儲指令。訪問ROM和RAM通常都快于訪問輔助存儲器。存儲器350可用于存儲用于執(zhí)行本文所描述的各種示例實施例的指令。在一項實施例中，存儲器350可包括模塊360。在一實施例中，模塊360代表設(shè)置在圖2所示的通知服務(wù)器204和/或API服務(wù)器206內(nèi)的通知信道斷連模塊。模塊360能夠?qū)嵤┩ㄖ诺罃噙B過程并允許通知服務(wù)器204與API服務(wù)器206交換消息。換言之，模塊360允許通知服務(wù)器204與API服務(wù)器206就客戶端202與通知服務(wù)器204之間的通知信道的斷連等進(jìn)行相互通信。應(yīng)理解，通過將可執(zhí)行指令編程和/或加載到服務(wù)器300上，處理器330、緩存和長期存儲器中的至少一個被改變，從而將服務(wù)器300的一部分轉(zhuǎn)換成特定機器或裝置，例如本發(fā)明宣揚的擁有新穎功能的多核轉(zhuǎn)發(fā)架構(gòu)。加載可執(zhí)行軟件至計算機所實現(xiàn)的功能可以通過現(xiàn)有技術(shù)中公知的設(shè)計規(guī)則轉(zhuǎn)換成硬件實施，這在電力工程和軟件工程領(lǐng)域是很基礎(chǔ)的。決定使用軟件還是硬件來實施一個概念通常取決于對設(shè)計穩(wěn)定性及待生產(chǎn)的單元數(shù)量的考慮，而不是從軟件領(lǐng)域轉(zhuǎn)換至硬件領(lǐng)域中所涉及的任何問題。通常，仍然頻繁改變的設(shè)計可優(yōu)先在軟件中實施，因為重新編寫硬件實施方式比重新編寫軟件設(shè)計更為昂貴。通常，穩(wěn)定及大規(guī)模生產(chǎn)的設(shè)計更適于在軟件中(例如，在ASIC中)實施，因為運行硬件實施的大規(guī)模生產(chǎn)比軟件實施更為便宜。設(shè)計通常可以以軟件形式進(jìn)行開發(fā)和測試，之后通過現(xiàn)有技術(shù)中公知的設(shè)計規(guī)則轉(zhuǎn)變成ASIC中等同的硬件實施，該ASIC硬線軟件指令。由新的ASIC控制的機器是一種特定機器或裝置，同樣地，編程和/或加載有可執(zhí)行指令的計算機可視為特定機器或裝置。本發(fā)明的任何處理可以通過使處理器(例如，通用多核處理器)執(zhí)行計算機程序來實施。在這種情況下，可以使用任何類型的非瞬時性計算機可讀介質(zhì)向計算機或網(wǎng)絡(luò)設(shè)備提供計算機程序產(chǎn)品。計算機程序產(chǎn)品可存儲在計算機或網(wǎng)絡(luò)設(shè)備中的非瞬時性計算機可讀介質(zhì)中。非瞬時性計算機可讀介質(zhì)包括任何類型的有形存儲介質(zhì)。非瞬時性計算機可讀介質(zhì)的示例包括磁性存儲介質(zhì)(例如，軟盤、磁盤、硬盤驅(qū)動器等)、光磁存儲介質(zhì)(例如，磁光盤)、只讀光盤(compactdiscread-onlymemory，CD-ROM)、可錄光碟(compactdiscrecordable，CD-R)、帶讀寫式光驅(qū)(compactdiscrewritable，CD-R/W)、數(shù)字多功能光盤(digitalversatiledisc，DVD)、藍(lán)(注冊商標(biāo))光(Blu-raydisc，BD)，以及半導(dǎo)體存儲器(例如，掩蔽ROM、可編程ROM(programmableROM，PROM)、可擦除PROM、快閃ROM，以及RAM)。還可以使用任何類型的瞬時性計算機可讀介質(zhì)向計算機或網(wǎng)絡(luò)設(shè)備提供計算機程序產(chǎn)品。瞬時性計算機可讀介質(zhì)的示例包括電信號、光信號和電磁波。瞬時性計算機可讀介質(zhì)可以經(jīng)由有線通信線路(例如，電線或光纖)或無線通信線路將程序提供給計算機。在一示例實施例中，通知服務(wù)器用于處理通知信道斷連。通知服務(wù)器包括：檢測模塊，檢測與表征狀態(tài)轉(zhuǎn)移(representationalstatetransfer，REST)客戶端對應(yīng)的通知信道的斷連；斷連模塊，向應(yīng)用服務(wù)器發(fā)送表明通知信道斷連的斷連請求；以及接收模塊，從應(yīng)用服務(wù)器接收表明REST客戶端的訂閱已刪除的響應(yīng)。在一些實施例中，通知服務(wù)器可包括用于執(zhí)行實施例中描述的任一步驟或步驟組合的其它或附加模塊。在一示例實施例中，應(yīng)用服務(wù)器用于處理通知信道斷連。應(yīng)用服務(wù)器包括：接收模塊，從通知服務(wù)器接收表明通知服務(wù)器與表征狀態(tài)轉(zhuǎn)移(representationalstatetransfer，REST)客戶端之間的通知信道斷連的斷連請求；以及響應(yīng)模塊，向通知服務(wù)器發(fā)送表明REST客戶端的訂閱已刪除的響應(yīng)。在一些實施例中，應(yīng)用服務(wù)器可包括用于執(zhí)行實施例中描述的任一步驟或步驟組合的其它或附加模塊。圖4為處理通知信道斷連的方法400的實施例的流程圖。在一實施例中，用于執(zhí)行方法400的指令存儲在通知信道斷連模塊360中，方法400使用處理器330來實施。方法400在客戶端202與通知服務(wù)器204之間的通知信道斷連時實施，以通知API服務(wù)器206，客戶端202與通知服務(wù)器204之間的通知信道斷連，因此可以刪除有關(guān)客戶端202的訂閱。在方框402中，檢測到與REST客戶端對應(yīng)的通知信道的斷連。在一實施例中，圖2的通知服務(wù)器204能夠檢測到通知信道的故障或斷連。在一些實施例中，通知服務(wù)器204在長輪詢過程的“心跳”不再能感覺到或已停止時，確定通知信道已發(fā)生故障。在一些實施例中，如果通知服務(wù)器204在預(yù)定時間內(nèi)沒有從客戶端202接收到通信，則確定通知信道斷連。在方框404中，向應(yīng)用服務(wù)器發(fā)送表明通知信道斷連的斷連請求。在一實施例中，在已檢測到通知信道斷連時，圖2的通知服務(wù)器204向API服務(wù)器206發(fā)送斷連請求。該請求向API服務(wù)器206表明客戶端202與通知服務(wù)器204之間的通知信道斷連。在一些實施例中，斷連請求包括回調(diào)URL和在客戶端202上運行的應(yīng)用的用戶標(biāo)識(例如，用戶ID)。在一些實施例中，斷連請求的格式是HTTP。例如，可使用HTTPPOST操作來實施斷連請求。在方框406中，從應(yīng)用服務(wù)器接收表明REST客戶端的訂閱已刪除的響應(yīng)。在一實施例中，在接收到斷連請求時，圖2的API服務(wù)器206刪除與客戶端202對應(yīng)的訂閱。例如，API服務(wù)器206根據(jù)從通知服務(wù)器204接收的用戶ID和回調(diào)URL刪除訂閱。然后，API服務(wù)器206向通知服務(wù)器204發(fā)回響應(yīng)。在一實施例中，該響應(yīng)表明關(guān)于客戶端202的訂閱(例如，與用戶ID和/或回調(diào)URL對應(yīng)的訂閱)已刪除。通過在客戶端202與通知服務(wù)器204之間的通知信道已斷連時刪除客戶端202的訂閱，避免了服務(wù)通知的無效訂閱。換言之，去除了無效資源。圖5為處理通知信道斷連的方法500的一實施例的流程圖。在一實施例中，用于執(zhí)行方法500的指令存儲在通知信道斷連模塊360中，方法500使用處理器330來實施。方法500在客戶端202與通知服務(wù)器204之間的通知信道斷連時實施，以通知API服務(wù)器206，客戶端202與通知服務(wù)器204之間的通知信道斷連，因此可以刪除有關(guān)客戶端202的訂閱。在方框502中，從通知服務(wù)器接收表明通知服務(wù)器與REST客戶端之間的通知信道斷連的斷連請求。在一實施例中，圖2的通知服務(wù)器204能夠檢測到通知信道的故障或斷連。在一些實施例中，通知服務(wù)器204在長輪詢過程的“心跳”不再能感覺到或已停止時，確定通知信道已發(fā)生故障。在一些實施例中，如果通知服務(wù)器204在預(yù)定時間內(nèi)沒有從客戶端202接收到通信，則確定通知信道斷連。在一實施例中，在已檢測到通知信道斷連時，圖2的通知服務(wù)器204向API服務(wù)器206發(fā)送斷連請求。該請求向API服務(wù)器206表明客戶端202與通知服務(wù)器204之間的通知信道斷連。在一些實施例中，斷連請求包括回調(diào)URL和在客戶端202上運行的應(yīng)用的用戶標(biāo)識(例如，用戶ID)。在一些實施例中，斷連請求的格式是HTTP。例如，可使用HTTPPOST操作來實施斷連請求。在方框504中，向通知服務(wù)器發(fā)送表明REST客戶端的訂閱已刪除的響應(yīng)。在一實施例中，在接收到斷連請求時，圖2的API服務(wù)器206刪除與客戶端202對應(yīng)的訂閱。例如，API服務(wù)器206根據(jù)從通知服務(wù)器204接收的用戶ID和回調(diào)URL刪除訂閱。然后，API服務(wù)器206向通知服務(wù)器204發(fā)回響應(yīng)。在一實施例中，該響應(yīng)表明關(guān)于客戶端202的訂閱(例如，與用戶ID和/或回調(diào)URL對應(yīng)的訂閱)已刪除。通過在客戶端202與通知服務(wù)器204之間的通知信道已斷連時刪除客戶端202的訂閱，避免了服務(wù)通知的無效訂閱。換言之，去除了無效資源。雖然本發(fā)明中已提供若干實施例，但應(yīng)理解，在不脫離本發(fā)明的精神或范圍的情況下，本發(fā)明所公開的系統(tǒng)和方法可以以許多其它特定形式來體現(xiàn)。本發(fā)明的實例應(yīng)被視為說明性而非限制性的，且本發(fā)明并不限于本文本所給出的細(xì)節(jié)。例如，各種元件或部件可以在另一系統(tǒng)中組合或合并，或者某些特征可以省略或不實施。此外，在不脫離本發(fā)明的范圍的情況下，各種實施例中描述和說明為離散或單獨的技術(shù)、系統(tǒng)、子系統(tǒng)和方法可以與其它系統(tǒng)、模塊、技術(shù)或方法進(jìn)行組合或合并。展示或論述為彼此耦合或直接耦合或通信的其它項也可以采用電方式、機械方式或其它方式通過某一接口、設(shè)備或中間部件間接地耦合或通信。其它變化、替代和改變的示例可以由本領(lǐng)域的技術(shù)人員在不脫離本文精神和所公開的范圍的情況下確定。在一示例實施例中，通知服務(wù)器用于處理通知信道斷連。通知服務(wù)器包括：檢測模塊，檢測與表征狀態(tài)轉(zhuǎn)移(representationalstatetransfer，REST)客戶端對應(yīng)的通知信道的斷連；斷連模塊，向應(yīng)用服務(wù)器發(fā)送表明通知信道斷連的斷連請求；以及接收模塊，從應(yīng)用服務(wù)器接收表明REST客戶端的訂閱已刪除的響應(yīng)。在一些實施例中，通知服務(wù)器可包括用于執(zhí)行實施例中描述的任一步驟或步驟組合的其它或附加模塊。在一示例實施例中，應(yīng)用服務(wù)器用于處理通知信道斷連。應(yīng)用服務(wù)器包括：接收模塊，從通知服務(wù)器接收表明通知服務(wù)器與表征狀態(tài)轉(zhuǎn)移(representationalstatetransfer，REST)客戶端之間的通知信道斷連的斷連請求；以及響應(yīng)模塊，向通知服務(wù)器發(fā)送表明REST客戶端的訂閱已刪除的響應(yīng)。在一些實施例中，應(yīng)用服務(wù)器可包括用于執(zhí)行實施例中描述的任一步驟或步驟組合的其它或附加模塊。當(dāng)前第1頁1 2 3 當(dāng)前第1頁1 2 3