TW201828019A - 資訊處理方法及裝置 - Google Patents

Abstract

本發明公開了一種資訊處理方法及裝置，該方法包括：根據用戶端上產生的、針對服務端提供的至少一個服務介面的介面調用請求，以及所述用戶端上的配置資訊的狀態資訊，產生包含所述狀態資訊的服務請求；將所述服務請求發送給所述服務端。透過本發明，用戶端可以利用已有的任一服務介面獲取配置資訊的更新資訊，而不需要為了獲取該更新資訊單獨維護一個定時執行緒，因此，可以減輕用戶端的負擔。

Description

資訊處理方法及裝置

本發明關於電腦技術領域，尤其關於一種資訊處理方法及裝置。

在互聯網時代，隨著終端的普及，各類應用的數量也大大增加，給人們的日常生活和工作帶來了便利。所述終端包括但不限於：手機、個人電腦、平板電腦、智慧手錶、車載台，等等。

一般地，應用的用戶端搭載於終端上，而服務端搭載於該應用的伺服器或終端上。在終端上安裝應用的用戶端後，該用戶端一般會包含有配置資訊，而在使用該用戶端的過程中，該用戶端可能經常需要從服務端獲取更新的配置資訊或其他配置資訊(為了便於描述，所述更新的配置資訊、所述其他配置資訊可以統稱為：配置資訊的更新資訊)，以實現對用戶端的更新和功能升級。

例如，對於某種資訊卡片應用，該資訊卡片應用的用戶端的配置資訊，以及該配置資訊的更新資訊包括但不限於：介面範本、全域應用設定資訊、場景引擎規則、功能 表資訊，等等。

在現有技術中，用戶端可以採用定時時鐘方案，從服務端獲取配置資訊的更新資訊。具體的，用戶端可以啟動一個定時執行緒，定時調用服務端提供的、用於更新配置資訊的介面，以請求查詢是否有該配置資訊的更新資訊，則服務端接收到請求後，當查詢到有更新資訊時，將該更新資訊返回給用戶端。

但是，在採用現有技術的情況下，用戶端啟動後，所述定時執行緒會一直佔用用戶端部分資源，用戶端的負擔較大。

本發明實施例提供一種資訊處理方法及裝置，用以解決現有技術中的用戶端獲取配置資訊的更新資訊的方法，導致用戶端的負擔較大的問題。

本發明實施例提供的一種資訊處理方法，包括：根據用戶端上產生的、針對服務端提供的至少一個服務介面的介面調用請求，以及所述用戶端上的配置資訊的狀態資訊，產生包含所述狀態資訊的服務請求；將所述服務請求發送給所述服務端。

本發明實施例提供的一種資訊處理裝置，包括：產生模組，用於根據用戶端上產生的、針對服務端提供的至少一個服務介面的介面調用請求，以及所述用戶端上的配置資訊的狀態資訊，產生包含所述狀態資訊的服務 請求；發送模組，用於將所述服務請求發送給所述服務端。

本發明實施例提供另一種資訊處理方法及裝置，用以解決現有技術中的用戶端獲取配置資訊的更新資訊的方法，導致用戶端的負擔較大的問題。

本發明實施例提供的另一種資訊處理方法，包括：接收用戶端發送的服務請求，其中，所述服務請求包括所述用戶端針對服務端提供的至少一個服務介面的介面調用請求，以及所述用戶端上的配置資訊的狀態資訊；根據所述服務請求中包含的所述狀態資訊，確定並向所述用戶端返回更新指示資訊，所述更新指示資訊用於指示所述配置資訊的更新資訊。

本發明實施例提供的另一種資訊處理裝置，包括：接收模組，用於接收用戶端發送的服務請求，其中，所述服務請求包括所述用戶端針對服務端提供的至少一個服務介面的介面調用請求，以及所述用戶端上的配置資訊的狀態資訊；返回模組，用於根據所述服務請求中包含的所述狀態資訊，確定並向所述用戶端返回更新指示資訊，所述更新指示資訊用於指示所述配置資訊的更新資訊。

本發明實施例提供一種終端，包括：記憶體，用於儲存處理器可執行指令；處理器，耦合到所述記憶體，用於讀取所述記憶體儲存的可執行指令，作為回應，執行如下操作：根據用戶端 上產生的、針對服務端提供的至少一個服務介面的介面調用請求，以及所述用戶端上的配置資訊的狀態資訊，產生包含所述狀態資訊的服務請求；將所述服務請求發送給所述服務端。

本發明實施例提供另一種終端，包括：記憶體，用於儲存處理器可執行指令；處理器，耦合到所述記憶體，用於讀取所述記憶體儲存的可執行指令，作為回應，執行如下操作：接收用戶端發送的服務請求，其中，所述服務請求包括所述用戶端針對服務端提供的至少一個服務介面的介面調用請求，以及所述用戶端上的配置資訊的狀態資訊；根據所述服務請求中包含的所述狀態資訊，確定並向所述用戶端返回更新指示資訊，所述更新指示資訊用於指示所述配置資訊的更新資訊。

本發明實施例透過上述至少一種技術方案，用戶端可以利用已有的任一服務介面獲取配置資訊的更新資訊，而不需要為了獲取該更新資訊單獨維護一個定時執行緒，因此，可以減輕用戶端的負擔。

S101、S102‧‧‧方法步驟

S201-S207‧‧‧方法步驟

S302、S302‧‧‧方法步驟

S401-S411‧‧‧方法步驟

601‧‧‧產生模組

603‧‧‧發送模組

604‧‧‧獲取模組

701‧‧‧接收模組

702‧‧‧返回模組

801‧‧‧記憶體

802‧‧‧處理器

901‧‧‧記憶體

902‧‧‧處理器

此處所說明的附圖用來提供對本發明的進一步理解，構成本發明的一部分，本發明的示意性實施例及其說明用於解釋本發明，並不構成對本發明的不當限定。在附圖中： 圖1為本發明實施例提供的資訊處理方法的過程；圖2為本發明實施例提供的，在一種實際應用場景下，用戶端上的代理單元的實現方式和工作方式；圖3為本發明實施例提供的另一種資訊處理方法的過程；圖4為本發明實施例提供的，在一種實際應用場景下，實施所述資訊處理方法時，用戶端和服務端的交互示意圖；圖5為本發明實施例提供的，在一種實際應用場景下，適用於實施所述資訊處理方法的系統結構示意圖；圖6為本發明實施例提供的對應於圖1的資訊處理裝置結構示意圖；圖7為本發明實施例提供的對應於圖3的資訊處理裝置結構示意圖；圖8為本發明實施例提供的對應於圖1的終端示意圖；圖9為本發明實施例提供的對應於圖3的終端示意圖。

為使本發明的目的、技術方案和優點更加清楚，下面將結合本發明具體實施例及相應的附圖對本發明技術方案進行清楚、完整地描述。顯然，所描述的實施例僅是本發明一部分實施例，而不是全部的實施例。基於本發明中的 實施例，本領域普通技術人員在沒有做出創造性勞動前提下所獲得的所有其他實施例，都屬於本發明保護的範圍。

在本發明實施例中，對於任一應用，該應用的服務端可以為該應用的用戶端提供不止一項服務。

例如，對於即時通訊應用，服務端提供的服務包括但不限於：查詢通訊訊息、傳輸通訊訊息、查詢指定通訊帳號的公開資訊、傳輸檔，等等。

又例如，對於視頻應用，服務端提供的服務包括但不限於：視頻點播、視頻直播、視頻離線下載，等等。

服務端可以預先針對每項服務，向用戶端提供用於獲取該項服務的服務介面，相應的，用戶端可以產生針對該服務介面的介面調用請求，並透過該服務介面發送給服務端，則服務端透過該服務介面對應的介面實現單元，對該介面調用請求進行處理，進而可以向用戶端返回該項服務。可以看到，各項服務對應的服務介面是已經存在的，且有相應的服務進程為服務介面提供資源支援。

在本發明實施例中，利用這些已經存在的服務介面和對應的服務進程，不僅可以獲得對應的服務，還可以處理一些額外的事務，從而可以不用為所述額外的事務單獨提供介面和進程，這樣的話，不僅可以減輕服務端和用戶端的負擔，也可以減少額外的網路調用，其中，所述額外的事務至少可以包括用戶端獲取自身上的配置資訊的更新資訊。本發明實施例主要基於這種情況進行詳細說明。

圖1為本發明實施例提供的資訊處理方法的過程，所 述資訊處理方法的執行主體可以是：應用的用戶端，或者，搭載有所述用戶端的終端。其中，所述終端包括但不限於：個人電腦、手機、平板電腦、智慧手錶、車載移動台等。所述的執行主體並不構成對本發明的限定，為了便於描述，圖1對應的各實施例均以執行主體是用戶端為例進行說明。

圖1中的過程具體可以包括以下步驟：

S101：根據用戶端上產生的、針對服務端提供的至少一個服務介面的介面調用請求，以及所述用戶端上的配置資訊的狀態資訊，產生包含所述狀態資訊的服務請求。

在本發明實施例中，用戶端當接收到服務獲取指令時，產生針對服務端提供的至少一個服務介面的介面調用請求。所述服務獲取指令可以是：用於指示用戶端從服務端，獲取服務端提供的任一項服務的指令。

本發明實施例對“接收服務獲取指令”這一動作的觸發因素並不做限定，在實際應用中，這一動作可以由用戶對用戶端的操作觸發，也可以由用戶端根據預設業務邏輯自動觸發。

例如，使用者在使用即時通訊應用時，可能會在應用介面編輯一條通訊訊息，並點擊“發送”按鈕，將該條通訊訊息發送給另一位元用戶。在該例中，可以認為，該“發送”按鈕被按下後，用戶端即接收到一條服務獲取指令，該條服務獲取指令用於指示用戶端從服務端提供的“傳輸通訊訊息”這項服務對應的服務介面獲取服務。

在本發明實施例中，所述介面調用請求可以包含所述至少一個服務介面的介面函數，以及所述介面函數的調用參數，其中，調用參數可以是由服務獲取指令指定的，也可以是用戶在用戶端上即時地輸入的。

在本發明實施例中，除了要獲取介面調用請求對應的服務以外，同時還可以獲取用戶端上的配置資訊的更新資訊，因此，可以不直接向服務端發送介面調用請求，而是對針對服務介面和/或介面調用請求進行特定處理，以加入獲取該更新資訊所需要的額外的資訊(也即，用戶端上的配置資訊的狀態資訊)，進而將特定處理後產生的請求發送給服務端。在本發明實施例中，所述特定處理至少可以包括兩種，下面對這兩種分別進行說明。

第一種，可以預先對用戶端上用於產生介面調用請求的服務介面單元進行修改，以加入包含所述狀態資訊的處理邏輯，這樣的話，透過修改後的服務介面單元，可以產生包含有所述狀態資訊的介面調用請求，併發送給服務端。第一種處理方法不用改變用戶端上各單元的結構。

第二種，也即步驟S101對應的處理方法。具體的，可以預先在用戶端上增加代理單元，則用戶端可以將產生的介面調用請求傳遞給代理單元，由代理單元執行步驟S101，進而可以將產生的、包含所述狀態資訊的服務請求發送給服務端。第二種處理方法實現成本較低，對用戶端和服務端上已有的介面影響較小。

在實際應用中，可以根據應用場景的具體情況，在以 上兩種處理方法中選擇更適用的方法。本發明實施例主要是基於上述的第二種處理方法進行說明的。

進一步的，為了便於理解，下面對所述配置資訊進行說明。

安裝應用的用戶端後，該用戶端一般會包含有配置資訊，而在使用該用戶端的過程中，該用戶端可能經常需要從服務端獲取更新的配置資訊或其他配置資訊(為了便於描述，所述更新的配置資訊、所述其他配置資訊可以統稱為：配置資訊的更新資訊)，以實現對用戶端的更新和功能升級。

需要說明的是，本發明實施例對所述配置資訊和所述配置資訊的更新資訊的格式、檔案類型、具體內容並不做限定。在實際應用中，所述配置資訊和所述配置資訊的更新資訊可以是：介面範本、全域應用設定資訊、場景引擎規則、功能表資訊、追加內容下載包、應用補丁，等等。

S102：將所述服務請求發送給所述服務端。

在本發明實施例中，可以透過步驟S101中提到的所述的至少一個服務介面，也可以透過服務端提供的其他服務介面，將服務請求發送給所述服務端。

在本發明實施例中，服務端在接收到服務資訊後，可以根據服務資訊中包含的所述狀態資訊，向用戶端返回更新指示資訊，以便於用戶端根據更新指示資訊，獲取配置資訊的更新資訊。

所述更新指示資訊可以用於指示是否有配置資訊的更 新資訊，以及有哪些更新資訊，等等。例如，所述更新指示資訊可以是所述配置資訊的更新資訊，可以是所述配置資訊的更新資訊的標識，也可以是所述配置資訊的更新資訊的下載位址，等等。

在本發明實施例中，對於用戶端根據更新指示資訊，獲取配置資訊的更新資訊這一步驟，可以有多種實施方式。

例如，當更新資訊的資料量較少時，可以將更新資訊攜帶在更新指示資訊中，則用戶端可以從更新指示資訊中直接獲取到更新資訊，這樣的話，可以降低用戶端與服務端之間的訊息交互次數，節省網路資源。

又例如，當更新資訊的資料量較多時，可以將更新資訊的標識攜帶在更新指示資訊，後續用戶端可以根據更新資訊的標識，在網路空閒時或是其他指定時刻從服務端下載更新資訊，這樣的話，可以提高獲取更新資訊的成功率，也可以減輕用戶端的負擔。

透過上述方法，用戶端可以利用已有的任一服務介面獲取配置資訊的更新資訊，而不需要為了獲取該更新資訊單獨維護一個定時執行緒，因此，可以減輕用戶端的負擔，其中，所述負擔包括對處理器資源、記憶體資源、電量資源等資源的消耗。

不僅如此，由於上述方法可以將查詢以及獲取配置資訊的更新資訊這一動作的觸發時機，融入到用戶端與服務端提供的任一服務介面的交互過程中，因此，沒有增加額 外的針對服務端的網路調用，而且也可以比較及時地獲取更新資訊，而不用像在現有技術中需要等待定時執行緒觸發獲取更新資訊。

例如，使用者使用用戶端上的即時通訊應用發送即時通訊訊息(向服務端請求獲取“傳輸通訊訊息”這項服務)時，可以觸發用戶端向服務端發送服務請求，服務端成功回應該服務請求後，用戶端不僅可以獲取到服務端提供的“傳輸通訊訊息”這項服務，還可以獲得配置資訊的更新資訊。

需要說明的是，以上只是用“傳輸通訊訊息”這項服務舉例說明，在實際應用中，用戶端在獲取任一項服務的過程中，也可以透過上述方法，獲得配置資訊的更新資訊，或者，完成其他額外的事務。

為了便於理解，下面對圖1中的步驟進一步地詳細說明。

在本發明實施例中，服務請求中包含的所述狀態資訊可以是：可用於讓服務端確定用戶端上的配置資訊是否存在更新資訊的任意資訊。在實際應用中，該狀態資訊可以是該配置資訊的最新更新時間，也可以是該配置資訊的標識，等等。以所述配置資訊是介面範本為例進行說明。

假定用戶端上的配置資訊包括兩個介面範本，名稱分別為“介面範本1”、“介面範本2”，其中，用戶端下載到這兩個介面範本的時間是2014年1月1日。該配置資訊的狀態資訊可以是“介面範本1”和“介面範本2”，服務端 根據該狀態資訊可以查詢自身上是否保存有用戶端上沒有的介面範本；類似的，該配置資訊的狀態資訊也可以是時間2014年1月1日，服務端根據該時間可以查詢服務端在該時間以後更新的介面範本，也即，用戶端上沒有的介面範本。進而服務端產生並用戶端返回更新指示資訊，該更新指示資訊可以是所述更新的介面範本，或所述更新的介面範本的名稱，等等。

在本發明實施例中，狀態資訊可以以不同的方式包含在服務請求中。

例如，狀態資訊透過所述服務請求的預定欄位進行保存，包含在所述服務請求中，或者，可以將狀態資訊寫入檔或訊息中，由服務請求攜帶寫入了狀態資訊的檔或訊息。前一種方案實現成本較小，後一種方案可以對狀態資訊的檔或訊息進一步地加密等操作，以提高資訊安全性，可以根據實際應用場景，選擇更適用的方案。在本發明實施例中，主要是基於前一種方案進行說明的。

在本發明實施例中，步驟S101中的介面調用請求可以包含所述至少一個服務介面的介面函數，以及所述介面函數的調用參數。

對於步驟S101，根據用戶端上產生的、針對服務端提供的至少一個服務介面的介面調用請求，以及所述用戶端上的配置資訊的狀態資訊，產生包含所述狀態資訊的服務請求，具體可以包括：確定所述介面調用請求對應的代理實現類，其中，所述代理實現類是根據所述介面函數和 所述預定欄位產生的；根據所述代理實現類、所述介面函數的調用參數和所述狀態資訊，產生包含所述狀態資訊的服務請求。需要說明的是，本發明實施例對所述預定欄位的名稱、位元組數等資訊並不做限定。

在本發明實施例中，不同的介面調用請求可以對應於不同的代理實現類，透過代理實現類可以在用戶端上的原有介面的功能的基礎上修改或擴展，且不影響原有介面的邏輯。

服務請求用於向服務端請求獲取：該介面函數對應的服務，以及用戶端上的配置資訊的更新資訊。本發明實施例對產生代理實現類的產生方式並不做限定，可以是用戶端上預設的代理單元產生的，也可以是由用戶端上已有任一單元產生的。

服務請求可以是一個請求；也可以是由至少兩個子請求組成的請求，其中，某個子請求可以用於請求獲取該服務，另一個子請求可以用於請求獲取該更新資訊，等等。對於後一種情況，在將服務請求發送給服務端的過程中，將該服務請求包含的至少兩個子請求同時發送給服務端，也可以按照預定發送順序，將至少兩個子請求分別發送給服務端，本發明實施例對所述預定發送順序並不做限定。

進一步的，根據所述代理實現類、所述介面函數的調用參數和所述狀態資訊，產生包含所述狀態資訊的服務請求，具體可以包括：根據所述代理實現類，對所述介面函數的調用參數進行轉換，產生服務參數；獲取所述狀態資 訊，並透過所述預定欄位保存所述狀態資訊；根據所述代理實現類、所述服務參數和保存了所述狀態資訊的所述預定欄位，產生包含所述狀態資訊的服務請求。

所述轉換過程中關於的操作包括但不限於：映射操作、封裝操作、參數修改操作、許可權修改操作、等等。本發明實施例對用戶端上負責管理、維護以及使用所述預定欄位的單元並不做限定，可以由代理單元負責，也可以由其他單元負責。

在實際應用中，當用戶端上預設有代理單元時，可以由該代理單元實現步驟S101，這樣的話，便於用戶端管理各介面調用請求的發送過程。需要說明的是，本發明實施例對於所述代理單元的實現方式並不做限定。為了便於理解，下面對在一種實際應用場景下，可以採用的代理單元的實現方式，以及代理單元的工作方式舉例進行說明。

代理單元在用戶端上運行，假定在服務端提供的某服務介面中定義有兩個介面函數，如下所示：Public interface ItemQueryService{ /** *查詢商品列表 *@param itemCond *@return */ Public List<ItemEntity> queryItemList(ItemEntity itemCond); /** *查詢最受歡迎的幾個商品列表 *@return */ Public List<ItemEntity> queryTopItemList( ); }

如圖2所示，代理單元的實現方式和工作方式具體可以包括以下步驟(各所述步驟的執行主體可以為該代理單元)：

S201：構造工廠類，其中，所述工廠類中包含用於創建代理實現類的函數。

調用代碼舉例說明：TPSClient client=TPSClient.getTpsClient( ); ItemQueryService service= Client.getService(“com.yunos.item.service.ItemQueryService”,ItemQueryServ ice.class); List<ItemEntity> list=service.queryTopItemList( ); 所述工廠類可以為TPSClient，所述函數可以為TPSClient.getTpsClient( )。

S202：根據所述函數，為服務介面創建對應的代理實現類。

所述服務介面可以為ItemQueryService，創建的該代理實現類也即為針對該服務介面的介面調用請求對應的代理實現類。

S203：根據接收到的介面調用請求，在所述代理實現類中，構造請求物件，其中所述請求物件用於傳遞與針對 服務介面的介面調用請求相關的資訊。

繼續調用代碼舉例說明：Request req=new Request( ); req.setServiceName(service); req.setMethod(method.getName( )); req.setParameters(GsonUtil.toJson(args)); 其中，所述請求物件可以是req，所述相關的資訊可以是調用參數、介面函數等。

S204：將介面調用請求包含的調用參數進行轉換後，保存在所述請求對象中。

具體的，可以將調用參數轉換為超文字傳輸協定(HyperText Transfer Protocol，http)請求參數，其中，parameters中是對調用參數轉換產生的json字串。

S205：獲取用戶端上的配置資訊的狀態資訊。

以所述狀態資訊為配置資訊的最新更新時間為例進行說明，可以將最新更新時間透過預定欄位(如gmtFlag欄位)進行保存和傳遞。另外，若用戶端並未記錄狀態資訊，則後續可以向服務端發送預設值，如0。

S206：根據代理實現類、請求參數和狀態資訊，產生包含該狀態資訊的服務請求。

S207：將服務請求透過服務介面，發送給服務端。

服務端透過服務介面接收到服務請求後，一方面可以根據所述服務請求，解析出介面調用請求，進而透過該服務介面的實現單元為用戶端返回對應的服務；另一方面， 可以根據服務請求包含的狀態資訊，確定更新指示資訊並返回給用戶端，以便於用戶端根據該更新指示資訊獲取配置資訊的更新資訊。

因此，對於步驟S102，在將所述服務請求發送給所述服務端，還可以執行如下步驟：接收所述服務端根據所述服務請求中包含的所述狀態資訊，返回的更新指示資訊；根據所述更新指示資訊，獲取所述配置資訊的更新資訊。

例如，在狀態資訊是配置資訊的最新更新時間的情況下，服務端接收到包含配置資訊的最新更新時間(為了便於描述，稱為：用戶端更新時間)的服務請求後，可以將用戶端更新時間，與服務端保存的配置資訊的最新更新時間(為了便於描述，稱為：服務端更新時間)進行比較。若服務端更新時間大於用戶端更新時間，則可以表示服務端保存有用戶端尚未獲得的更新資訊，進而服務端可以將該更新資訊或該更新資訊的標識作為更新指示資訊，返回給用戶端；若服務端更新時間不大於用戶端更新時間，則可以表示服務端未保存有用戶端尚未獲得的更新資訊，也即，用戶端上的配置資訊已是最新，目前無需更新，在這種情況下，服務端向用戶端返回的更新指示資訊也可以用於告知用戶端無需更新配置資訊。

在本發明實施例中，所述更新指示資訊可以包括：所述配置資訊的更新資訊的標識，或者，所述配置資訊的更新資訊；等等。

當所述更新指示資訊包括所述配置資訊的更新資訊的標識時，根據所述更新指示資訊，獲取所述配置資訊的更新資訊，具體可以包括：根據所述配置資訊的更新資訊的標識，從所述服務端獲取所述配置資訊的更新資訊。

當所述更新指示資訊包括所述配置資訊的更新資訊時，根據所述更新指示資訊，獲取所述配置資訊的更新資訊，具體可以包括：從所述更新指示資訊中，獲取所述配置資訊的更新資訊。

以上是從用戶端角度，說明的本發明實施例提供的資訊處理方法，基於同樣的思路，本發明實施例還提供了對應於圖1的另一種資訊處理方法，所述另一種資訊處理方法是從服務端角度進行說明的，如圖3所示。

圖3為本發明實施例提供的另一種資訊處理方法的過程，所述另一種資訊處理方法的執行主體可以是：應用的服務端，或者搭載有所述服務端的終端或伺服器。所述的執行主體並不構成對本發明的限定，為了便於描述，圖3對應的各實施例均以執行主體是所述服務端為例進行說明。

圖3中的過程具體可以包括以下步驟：

S301：接收用戶端發送的服務請求，其中，所述服務請求包括所述用戶端針對服務端提供的至少一個服務介面的介面調用請求，以及所述用戶端上的配置資訊的狀態資訊。

S302：根據所述服務請求中包含的所述狀態資訊，確 定並向所述用戶端返回更新指示資訊，所述更新指示資訊用於指示所述配置資訊的更新資訊。

在本發明實施例中，服務端接收到服務請求後，一方面可以由接收服務請求的服務介面對應的服務介面實現單元返回對應的服務；另一方面，可以由服務請求包含的狀態資訊，確定更新指示資訊，或者，該服務介面也可以將該狀態資訊傳遞給服務端上預設的訊息處理單元，由於該訊息處理單元根據該狀態資訊，確定更新指示資訊並返回給用戶端，以便於用戶端根據該更新指示資訊，獲取配置資訊的更新資訊。

透過上述方法，用戶端可以利用服務端提供的任一服務介面，獲取配置資訊的更新資訊，而不需要為了獲取該更新資訊單獨維護一個定時執行緒，因此，可以減輕用戶端的負擔，也可以減少服務端與用戶端之間的交互。

為了便於理解，下面對圖3中的步驟進一步地詳細說明。

在本發明實施例中，在服務端上預設有訊息處理單元時，對於步驟S302，根據所述服務請求中包含的所述狀態資訊，確定更新指示資訊，具體可以包括：所述服務請求中包含的所述狀態資訊傳遞給所述服務端上預設的訊息處理單元，以便於所述訊息處理單元根據所述狀態資訊，確定更新指示資訊。

需要說明的是，本發明實施例對“將所述狀態資訊傳遞給所述服務端上預設的訊息處理單元”所採用的傳遞方 式並不做限定。在實際應用場景下，服務介面獲得該狀態資訊後，可以構造一個包含該狀態資訊的訊息，並將該訊息發送給訊息處理單元。進一步的，該訊息可以以非同步方式發送給訊息處理單元，在這種情況下，所述訊息處理單元具體可以是非同步訊息處理單元。

服務介面除了可以將狀態資訊發送給訊息處理單元以外，還可以將諸如用戶端的標識等相關資訊發送給訊息處理單元，以便於訊息處理單元可以將產生的更新指示資訊正確地返回給用戶端。下面對更新指示資訊的確定方法進一步地說明。

前面已經提到，所述狀態資訊可以包括：所述用戶端上的配置資訊的最新更新時間，或者，所述用戶端上的配置資訊的標識。

則當所述狀態資訊包括所述用戶端上的配置資訊的最新更新時間時，可以按照如下方法，根據所述狀態資訊，確定更新指示資訊：當確定所述服務端上的配置資訊的最新更新時間大於所述用戶端上的配置資訊的最新更新時間時，確定所述服務端在所述用戶端上的配置資訊的最新更新時間之後，更新的所述配置資訊的更新資訊；根據所述更新資訊產生更新指示資訊，其中，所述更新指示資訊中包含所述更新資訊的標識或所述更新資訊；類似的，當所述狀態資訊包括所述用戶端上的配置資訊的標識時，可以按照如下方法，根據所述狀態資訊，確定更新指示資訊：當確定所述服務端上存在對應的標識與 所述用戶端上的配置資訊的標識不相同的配置資訊時，將確定出的配置資訊作為所述用戶端上的配置資訊的更新資訊；根據所述更新資訊產生更新指示資訊，其中，所述更新指示資訊中包含所述更新資訊的標識或所述更新資訊。

在本發明實施例中，服務介面和/或訊息處理單元可以透過長連接推送(Push)訊息通道，將更新指示資訊返回給用戶端，其中，所述長連接Push訊息通道可以只由一個應用使用，也可以由多個應用公用。進一步的，當更新指示資訊中包含更新資訊的標識、且未包含該更新資訊時，則用戶端尚未直接獲取到更新資訊，用戶端可以在接收到更新指示資訊後，再根據更新資訊的標識，透過該長連接Push訊息通道，或者，其他的通道，從服務端獲取更新資訊。

當用戶端透過所述其他的通道獲取更新資訊時，可以降低長連接Push訊息通道的資訊傳送負擔，防止自己長時間佔用長連接Push訊息通道，而且，用戶端和服務端還可以針對所述其他的訊息通道，實現指定的安全機制，以提高用戶端獲取更新資訊的可靠性。

以上為分別從用戶端角度和服務端角度，對本發明實施例提供的資訊處理方法的說明。為了便於理解，本發明實施例還提供了在一種實際應用場景下，實施所述資訊處理方法時，用戶端和服務端的交互示意圖，如圖4所示，所述交互具體可以包括以下步驟：

S401：用戶端接收服務獲取指令。

S402：用戶端根據所述服務獲取指令，產生針對服務端提供的至少一個服務介面的介面調用請求。

S403：用戶端將介面調用請求傳遞給用戶端上預設的代理單元。

S404：代理單元獲取用戶端上的配置資訊的狀態資訊。

S405：代理單元根據介面調用請求和狀態資訊，產生包含該狀態資訊的服務請求。

S406：代理單元透過服務介面，將服務請求發送給服務端。

S407：服務介面透過對應的服務介面實現單元對服務請求進行處理，以向用戶端返回對應的服務。

S408：服務介面將服務請求包含的該狀態資訊，透過非同步訊息發送給服務端上的非同步訊息處理單元。

S409：非同步訊息處理單元當確定服務端更新時間大於該狀態資訊中包含的用戶端更新時間時，確定服務端在用戶端更新時間後更新的配置資訊的更新資訊的標識，作為更新指示資訊。

S410：非同步訊息處理單元將更新指示資訊透過長連接Push通道返回給用戶端。

S411：用戶端根據更新指示資訊中的更新資訊的標識，從服務端獲取配置用戶端上的配置資訊的更新資訊。

進一步的，本發明實施例還提供了在一種實際應用場景下，適用於實施所述資訊處理方法的系統結構示意圖， 如圖5所示。

在圖5中，用戶端和服務端上分別包含有若干個單元，需要說明的是，圖5只是一種舉例說明的系統結構示意圖，在實際應用中，圖5中的各單元也可以進行合併和/或分拆，本發明實施例並不做限定。

在圖5中，公共請求代理單元和公共返回代理單元可以構成本發明實施例中所述的代理單元，系統的工作過程如下：服務介面調用單元在接收到服務獲取指令後，將對應的介面函數和調用參數傳遞給公共請求代理單元；公共請求代理單元根據該介面函數、該調用參數，以及用戶端上的配置資訊的狀態資訊，產生服務請求；公共請求代理單元將服務請求透過對應的服務介面，發送給服務端；服務介面透過服務介面實現單元，對服務請求進行處理，並向用戶端返回對應的服務；服務介面根據服務請求包含的狀態資訊，產生包含有該狀態資訊的訊息，並以非同步方式將該訊息傳遞給非同步訊息處理單元；非同步訊息處理單元根據接收到的該訊息，當確定服務端上存在配置資訊的更新資訊時，將該更新訊息的標識作為更新指示資訊，透過長連接Push訊息通道，發送給用戶端；用戶端透過Push訊息接收單元接收到更新指示資訊，根據更新訊息的標識，透過配置資訊查詢介面調用單 元與服務端的配置資訊查詢介面實現單元，獲取到配置資訊的更新資訊；配置資訊查詢介面調用單元將配置資訊的更新資訊傳遞給公共返回代理單元，以便於用戶端更新配置資訊。其中，公共返回代理單元可以用於記錄配置資訊的狀態資訊。

針對本發明實施例提供的資訊處理方法，基於同樣的思路，本發明實施例還提供相應的資訊處理裝置，如圖6、圖7所示。

圖6為本發明實施例提供的對應與圖1的資訊處理裝置結構示意圖，具體包括：產生模組601，用於根據用戶端上產生的、針對服務端提供的至少一個服務介面的介面調用請求，以及所述用戶端上的配置資訊的狀態資訊，產生包含所述狀態資訊的服務請求；發送模組603，用於將所述服務請求發送給所述服務端。

透過上述裝置，用戶端可以利用已有的任一服務介面獲取配置資訊的更新資訊，而不需要為了獲取該更新資訊單獨維護一個定時執行緒，因此，可以減輕用戶端的負擔。

所述狀態資訊包括：所述用戶端上的配置資訊的最新更新時間，或者，所述用戶端上的配置資訊的標識。

所述狀態資訊透過所述服務請求的預定欄位進行保 存，包含在所述服務請求中。

所述介面調用請求包含所述至少一個服務介面的介面函數，以及所述介面函數的調用參數；所述產生模組601具體用於：確定所述介面調用請求對應的代理實現類，其中，所述代理實現類是根據所述介面函數和所述預定欄位產生的；根據所述代理實現類、所述介面函數的調用參數和所述狀態資訊，產生包含所述狀態資訊的服務請求。

所述產生模組601具體用於：根據所述代理實現類，對所述介面函數的調用參數進行轉換，產生服務參數；獲取所述狀態資訊，並透過所述預定欄位保存所述狀態資訊；根據所述代理實現類、所述服務參數和保存了所述狀態資訊的所述預定欄位，產生包含所述狀態資訊的服務請求。

所述裝置還可以包括：獲取模組604，用於在所述發送模組601將所述服務請求發送給所述服務端之後，接收所述服務端根據所述服務請求中包含的所述狀態資訊，返回的更新指示資訊；根據所述更新指示資訊，獲取所述配置資訊的更新資訊。

所述更新指示資訊包括：所述配置資訊的更新資訊的標識，或者，所述配置資訊的更新資訊；當所述更新指示資訊包括所述配置資訊的更新資訊的標識時，所述發送模組具體用於：根據所述配置資訊的更新資訊的標識，從所述服務端獲取所述配置資訊的更新資 訊；當所述更新指示資訊包括所述配置資訊的更新資訊時，所述發送模組具體用於：從所述更新指示資訊中，獲取所述配置資訊的更新資訊。

具體的上述如圖6所示的裝置可以位於用戶端上。

圖7為本發明實施例提供的對應於圖3的資訊處理裝置結構示意圖，具體包括：接收模組701，用於接收用戶端發送的服務請求，其中，所述服務請求包括所述用戶端針對服務端提供的至少一個服務介面的介面調用請求，以及所述用戶端上的配置資訊的狀態資訊；返回模組702，用於根據所述服務請求中包含的所述狀態資訊，確定並向所述用戶端返回更新指示資訊，所述更新指示資訊用於指示所述配置資訊的更新資訊。

透過上述裝置，用戶端可以利用已有的任一服務介面獲取配置資訊的更新資訊，而不需要為了獲取該更新資訊單獨維護一個定時執行緒，因此，可以減輕用戶端的負擔。

所述返回模組702具體用於：將所述服務請求中包含的所述狀態資訊傳遞給所述服務端上預設的訊息處理單元，以便於所述訊息處理單元根據所述狀態資訊，確定更新指示資訊。

所述狀態資訊包括：所述用戶端上的配置資訊的最新更新時間，或者，所述用戶端上的配置資訊的標識； 當所述狀態資訊包括所述用戶端上的配置資訊的最新更新時間時，所述返回模組702按照如下方法，根據所述狀態資訊，確定更新指示資訊：當確定所述服務端上的配置資訊的最新更新時間大於所述用戶端上的配置資訊的最新更新時間時，確定所述服務端在所述用戶端上的配置資訊的最新更新時間之後，更新的所述配置資訊的更新資訊；根據所述更新資訊產生更新指示資訊，其中，所述更新指示資訊中包含所述更新資訊的標識或所述更新資訊；當所述狀態資訊包括所述用戶端上的配置資訊的標識時，所述返回模組702按照如下方法，根據所述狀態資訊，確定更新指示資訊：當確定所述服務端上存在對應的標識與所述用戶端上的配置資訊的標識不相同的配置資訊時，將確定出的配置資訊作為所述用戶端上的配置資訊的更新資訊；根據所述更新資訊產生更新指示資訊，其中，所述更新指示資訊中包含所述更新資訊的標識或所述更新資訊。

具體的上述如圖7所示的裝置可以位於服務端上。

基於同樣的思路，本發明實施例還提供相應的終端，如圖8、圖9所示。

圖8為本發明實施例提供的對應於圖1的終端示意圖，具體包括：記憶體801，用於儲存處理器可執行指令；處理器802，耦合到所述記憶體，用於讀取所述記憶 體儲存的可執行指令，作為回應，執行如下操作：根據用戶端上產生的、針對服務端提供的至少一個服務介面的介面調用請求，以及所述用戶端上的配置資訊的狀態資訊，產生包含所述狀態資訊的服務請求；將所述服務請求發送給所述服務端。

圖9為本發明實施例提供的對應於圖3的終端示意圖，具體包括：記憶體901，用於儲存處理器可執行指令；處理器902，耦合到所述記憶體，用於讀取所述記憶體儲存的可執行指令，作為回應，執行如下操作：接收用戶端發送的服務請求，其中，所述服務請求包括所述用戶端針對服務端提供的至少一個服務介面的介面調用請求，以及所述用戶端上的配置資訊的狀態資訊；根據所述服務請求中包含的所述狀態資訊，確定並向所述用戶端返回更新指示資訊，所述更新指示資訊用於指示所述配置資訊的更新資訊。

需要說明的是，在實際應用中，圖9中的終端可以作為伺服器使用。

本領域內的技術人員應明白，本發明的實施例可提供為方法、系統、或電腦程式產品。因此，本發明可採用完全硬體實施例、完全軟體實施例、或結合軟體和硬體方面的實施例的形式。而且，本發明可採用在一個或多個其中包含有電腦可用程式碼的電腦可用儲存媒體(包括但不限於磁碟記憶體、CD-ROM、光學記憶體等)上實施的電腦 程式產品的形式。

本發明是參照根據本發明實施例的方法、設備(系統)、和電腦程式產品的流程圖和/或方塊圖來描述的。應理解可由電腦程式指令實現流程圖和/或方塊圖中的每一流程和/或方塊、以及流程圖和/或方塊圖中的流程和/或方塊的結合。可提供這些電腦程式指令到通用電腦、專用電腦、嵌入式處理機或其他可程式設計資料處理設備的處理器以產生一個機器，使得透過電腦或其他可程式設計資料處理設備的處理器執行的指令產生用於實現在流程圖一個流程或多個流程和/或方塊圖一個方塊或多個方塊中指定的功能的裝置。

這些電腦程式指令也可儲存在能引導電腦或其他可程式設計資料處理設備以特定方式工作的電腦可讀記憶體中，使得儲存在該電腦可讀記憶體中的指令產生包括指令裝置的製造品，該指令裝置實現在流程圖一個流程或多個流程和/或方塊圖一個方塊或多個方塊中指定的功能。

這些電腦程式指令也可裝載到電腦或其他可程式設計資料處理設備上，使得在電腦或其他可程式設計設備上執行一系列操作步驟以產生電腦實現的處理，從而在電腦或其他可程式設計設備上執行的指令提供用於實現在流程圖一個流程或多個流程和/或方塊圖一個方塊或多個方塊中指定的功能的步驟。

在一個典型的配置中，計算設備包括一個或多個處理器(CPU)、輸入/輸出介面、網路介面和記憶體。

記憶體可能包括電腦可讀媒體中的非永久性記憶體，隨機存取記憶體(RAM)和/或非易失性記憶體等形式，如唯讀記憶體(ROM)或快閃記憶體(flash RAM)。記憶體是電腦可讀媒體的示例。

電腦可讀媒體包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現資訊儲存。資訊可以是電腦可讀指令、資料結構、程式的模組或其他資料。電腦的儲存媒體的例子包括，但不限於相變記憶體(PRAM)、靜態隨機存取記憶體(SRAM)、動態隨機存取記憶體(DRAM)、其他類型的隨機存取記憶體(RAM)、唯讀記憶體(ROM)、電可擦除可程式設計唯讀記憶體(EEPROM)、快閃記憶體或其他記憶體技術、唯讀光碟唯讀記憶體(CD-ROM)、數位多功能光碟(DVD)或其他光學儲存、磁盒式磁帶，磁帶磁磁片儲存或其他磁性存放裝置或任何其他非傳輸媒體，可用於儲存可以被計算設備訪問的資訊。按照本文中的界定，電腦可讀媒體不包括暫態性電腦可讀媒體(transitory media)，如調變的資料信號和載波。

還需要說明的是，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個......”限定的要素，並不排除 在包括所述要素的過程、方法、商品或者設備中還存在另外的相同要素。

以上所述僅為本發明的實施例而已，並不用於限制本發明。對於本領域技術人員來說，本發明可以有各種更改和變化。凡在本發明的精神和原理之內所作的任何修改、等同替換、改進等，均應包含在本發明的申請專利範圍的範圍之內。

Claims (22)

1. 一種資訊處理方法，其特徵在於，該方法包括：根據用戶端上產生的、針對服務端提供的至少一個服務介面的介面調用請求，以及該用戶端上的配置資訊的狀態資訊，產生包含該狀態資訊的服務請求；及將該服務請求發送給該服務端。
2. 如申請專利範圍第1項所述的方法，其中，該狀態資訊包括：該用戶端上的配置資訊的最新更新時間，或者，該用戶端上的配置資訊的標識。
3. 如申請專利範圍第1項所述的方法，其中，該狀態資訊透過該服務請求的預定欄位進行保存，包含在該服務請求中。
4. 如申請專利範圍第3項所述的方法，其中，該介面調用請求包含該至少一個服務介面的介面函數，以及該介面函數的調用參數；及根據用戶端上產生的、針對服務端提供的至少一個服務介面的介面調用請求，以及該用戶端上的配置資訊的狀態資訊，產生包含該狀態資訊的服務請求，具體包括：確定該介面調用請求對應的代理實現類，其中，該代理實現類是根據該介面函數和該預定欄位產生的；及根據該代理實現類、該介面函數的調用參數和該狀態資訊，產生包含該狀態資訊的服務請求。
5. 如申請專利範圍第4項所述的方法，其中，根據該代理實現類、該介面函數的調用參數和該狀態資訊，產生 包含該狀態資訊的服務請求，具體包括：根據該代理實現類，對該介面函數的調用參數進行轉換，產生服務參數；獲取該狀態資訊，並透過該預定欄位保存該狀態資訊；及根據該代理實現類、該服務參數和保存了該狀態資訊的該預定欄位，產生包含該狀態資訊的服務請求。
6. 如申請專利範圍第1項所述的方法，其中，將該服務請求發送給該服務端之後，還包括：接收該服務端根據該服務請求中包含的該狀態資訊，返回的更新指示資訊；及根據該更新指示資訊，獲取該配置資訊的更新資訊。
7. 如申請專利範圍第6項所述的方法，其中，該更新指示資訊包括：該配置資訊的更新資訊的標識，或者，該配置資訊的更新資訊；及當該更新指示資訊包括該配置資訊的更新資訊的標識時，根據該更新指示資訊，獲取該配置資訊的更新資訊，具體包括：根據該配置資訊的更新資訊的標識，從該服務端獲取該配置資訊的更新資訊；及當該更新指示資訊包括該配置資訊的更新資訊時，根據該更新指示資訊，獲取該配置資訊的更新資訊，具體包括：從該更新指示資訊中，獲取該配置資訊的更新資訊。
8. 一種資訊處理方法，其特徵在於，該方法包括：接收用戶端發送的服務請求，其中，該服務請求包括該用戶端針對服務端提供的至少一個服務介面的介面調用請求，以及該用戶端上的配置資訊的狀態資訊；及根據該服務請求中包含的該狀態資訊，確定並向該用戶端返回更新指示資訊，該更新指示資訊用於指示該配置資訊的更新資訊。
9. 如申請專利範圍第8項所述的方法，其中，根據該服務請求中包含的該狀態資訊，確定更新指示資訊，具體包括：將該服務請求中包含的該狀態資訊傳遞給該服務端上預設的訊息處理單元，以便於該訊息處理單元根據該狀態資訊，確定更新指示資訊。
10. 如申請專利範圍第8或9項所述的方法，其中，該狀態資訊包括：該用戶端上的配置資訊的最新更新時間，或者，該用戶端上的配置資訊的標識；當該狀態資訊包括該用戶端上的配置資訊的最新更新時間時，按照如下方法，根據該狀態資訊，確定更新指示資訊：當確定該服務端上的配置資訊的最新更新時間大於該用戶端上的配置資訊的最新更新時間時，確定該服務端在該用戶端上的配置資訊的最新更新時間之後，更新的該配置資訊的更新資訊；根據該更新資訊產生更新指示資訊，其中，該更新指示資訊中包含該更新資訊的標識或該更新 資訊；當該狀態資訊包括該用戶端上的配置資訊的標識時，按照如下方法，根據該狀態資訊，確定更新指示資訊：及當確定該服務端上存在對應的標識與該用戶端上的配置資訊的標識不相同的配置資訊時，將確定出的配置資訊作為該用戶端上的配置資訊的更新資訊；根據該更新資訊產生更新指示資訊，其中，該更新指示資訊中包含該更新資訊的標識或該更新資訊。
11. 一種資訊處理裝置，其特徵在於，該裝置包括：產生模組，用於根據用戶端上產生的、針對服務端提供的至少一個服務介面的介面調用請求，以及該用戶端上的配置資訊的狀態資訊，產生包含該狀態資訊的服務請求；及發送模組，用於將該服務請求發送給該服務端。
12. 如申請專利範圍第11項所述的裝置，其中，該狀態資訊包括：該用戶端上的配置資訊的最新更新時間，或者，該用戶端上的配置資訊的標識。
13. 如申請專利範圍第11項所述的裝置，其中，該狀態資訊透過該服務請求的預定欄位進行保存，包含在該服務請求中。
14. 如申請專利範圍第13項所述的裝置，其中，該介面調用請求包含該至少一個服務介面的介面函數，以及該介面函數的調用參數；及該產生模組具體用於：確定該介面調用請求對應的代 理實現類，其中，該代理實現類是根據該介面函數和該預定欄位產生的；根據該代理實現類、該介面函數的調用參數和該狀態資訊，產生包含該狀態資訊的服務請求。
15. 如申請專利範圍第14項所述的裝置，其中，該產生模組具體用於：根據該代理實現類，對該介面函數的調用參數進行轉換，產生服務參數；獲取該狀態資訊，並透過該預定欄位保存該狀態資訊；根據該代理實現類、該服務參數和保存了該狀態資訊的該預定欄位，產生包含該狀態資訊的服務請求。
16. 如申請專利範圍第11項所述的裝置，其中，該裝置還包括：獲取模組，用於在該發送模組將該服務請求發送給該服務端之後，接收該服務端根據該服務請求中包含的該狀態資訊，返回的更新指示資訊；根據該更新指示資訊，獲取該配置資訊的更新資訊。
17. 如申請專利範圍第16項所述的裝置，其中，該更新指示資訊包括：該配置資訊的更新資訊的標識，或者，該配置資訊的更新資訊；當該更新指示資訊包括該配置資訊的更新資訊的標識時，該發送模組具體用於：根據該配置資訊的更新資訊的標識，從該服務端獲取該配置資訊的更新資訊；及當該更新指示資訊包括該配置資訊的更新資訊時，該發送模組具體用於：從該更新指示資訊中，獲取該配置資訊的更新資訊。
18. 一種資訊處理裝置，其特徵在於，該裝置包括：接收模組，用於接收用戶端發送的服務請求，其中，該服務請求包括該用戶端針對服務端提供的至少一個服務介面的介面調用請求，以及該用戶端上的配置資訊的狀態資訊；及返回模組，用於根據該服務請求中包含的該狀態資訊，確定並向該用戶端返回更新指示資訊，該更新指示資訊用於指示該配置資訊的更新資訊。
19. 如申請專利範圍第18項所述的裝置，其中，該返回模組具體用於：將該服務請求中包含的該狀態資訊傳遞給該服務端上預設的訊息處理單元，以便於該訊息處理單元根據該狀態資訊，確定更新指示資訊。
20. 如申請專利範圍第18或19項所述的裝置，其中，該狀態資訊包括：該用戶端上的配置資訊的最新更新時間，或者，該用戶端上的配置資訊的標識；當該狀態資訊包括該用戶端上的配置資訊的最新更新時間時，該返回模組按照如下方法，根據該狀態資訊，確定更新指示資訊：當確定該服務端上的配置資訊的最新更新時間大於該用戶端上的配置資訊的最新更新時間時，確定該服務端在該用戶端上的配置資訊的最新更新時間之後，更新的該配置資訊的更新資訊；根據該更新資訊產生更新指示資訊，其中，該更新指示資訊中包含該更新資訊的標識或該更新資訊； 當該狀態資訊包括該用戶端上的配置資訊的標識時，該返回模組按照如下方法，根據該狀態資訊，確定更新指示資訊：及當確定該服務端上存在對應的標識與該用戶端上的配置資訊的標識不相同的配置資訊時，將確定出的配置資訊作為該用戶端上的配置資訊的更新資訊；根據該更新資訊產生更新指示資訊，其中，該更新指示資訊中包含該更新資訊的標識或該更新資訊。
21. 一種終端，其特徵在於，該終端包括：記憶體，用於儲存處理器可執行指令；及處理器，耦合到該記憶體，用於讀取該記憶體儲存的可執行指令，作為回應，執行如下操作：根據用戶端上產生的、針對服務端提供的至少一個服務介面的介面調用請求，以及該用戶端上的配置資訊的狀態資訊，產生包含該狀態資訊的服務請求；將該服務請求發送給該服務端。
22. 一種終端，其特徵在於，該終端包括：記憶體，用於儲存處理器可執行指令；及處理器，耦合到該記憶體，用於讀取該記憶體儲存的可執行指令，作為回應，執行如下操作：接收用戶端發送的服務請求，其中，該服務請求包括該用戶端針對服務端提供的至少一個服務介面的介面調用請求，以及該用戶端上的配置資訊的狀態資訊；根據該服務請求中包含的該狀態資訊，確定並向該用戶端返回更新指示資訊，該更新指示資訊用於指示該配置資訊的更新資訊。