本申請涉及計(jì)算機(jī)技術(shù)領(lǐng)域，尤其涉及一種請求發(fā)送方法及裝置。

背景技術(shù)：

隨著互聯(lián)網(wǎng)信息技術(shù)的不斷發(fā)展，各種互聯(lián)網(wǎng)資源(比如網(wǎng)絡(luò)存儲資源、安全監(jiān)控資源等)也不斷出現(xiàn)。

互聯(lián)網(wǎng)資源可以是以文本、圖片、音頻、視頻、軟件、數(shù)據(jù)庫等多種形式存在的。用戶可以將個人的照片、視頻、音頻等數(shù)據(jù)上傳至互聯(lián)網(wǎng)，作為互聯(lián)網(wǎng)資源共享給其他用戶。

而在實(shí)際使用中，用戶可能會期望對自己的互聯(lián)網(wǎng)資源或者他人共享的互聯(lián)網(wǎng)資源進(jìn)行某些操作，比如對個人的互聯(lián)網(wǎng)資源進(jìn)行查詢，或者對他人的互聯(lián)網(wǎng)資源進(jìn)行查詢，又或者是對他人的互聯(lián)網(wǎng)資源進(jìn)行獲取等等。

而如果將一個用戶的互聯(lián)網(wǎng)資源的操作權(quán)限向所有其他用戶開放，則可能會對用戶的信息安全造成很大的隱患。為了保證用戶的信息的安全，現(xiàn)有技術(shù)提出了一種用戶賬號操作權(quán)限分級機(jī)制，采用該機(jī)制可以對用戶瀏覽互聯(lián)網(wǎng)時所使用的賬號進(jìn)行權(quán)限等級劃分，用戶賬號的權(quán)限等級越高，則用戶可以執(zhí)行的操作也就越多，反之，用戶賬號的權(quán)限等級越低，則用戶可以執(zhí)行的操作也就越少。

假設(shè)，將用戶賬號的權(quán)限等級劃分成了A、B、C三個由高到低的級別，權(quán)限等級A可以查詢600兆(Mbyte，MB)的互聯(lián)網(wǎng)資源，權(quán)限等級B可以查詢400MB的互聯(lián)網(wǎng)資源進(jìn)行，而權(quán)限等級C可以查詢200MB的互聯(lián)網(wǎng)資源。在這種情況下，假設(shè)某用戶的賬號權(quán)限等級為C，該用戶正在使用該賬號閱讀漫畫，當(dāng)該用戶閱讀漫畫的流量累計(jì)超過200MB時，該用戶將無法繼續(xù)閱讀漫畫，此時如果用戶需要繼續(xù)閱讀漫畫時，則需要用戶對當(dāng)前使用的賬號的權(quán)限等級進(jìn)行提升，由于在對用戶賬號的權(quán)限等級進(jìn)行提升時，用戶需要終止當(dāng)前正在進(jìn)行的操作活動，且在權(quán)限等級提升后，無法自動切換回之前的操作活動，不便于用戶的使用。

因而如何在不影響用戶當(dāng)前操作請求發(fā)送連續(xù)性的前提下，完成對用戶賬號權(quán)限的提升成為現(xiàn)有技術(shù)亟待解決的問題。

技術(shù)實(shí)現(xiàn)要素：

本申請實(shí)施例提供一種請求發(fā)送方法及裝置，用以解決現(xiàn)有技術(shù)在提升用戶賬號權(quán)限時會造成請求發(fā)送中斷的問題；

本申請實(shí)施例還提供一種支付請求發(fā)送方法及裝置，用以解決現(xiàn)有技術(shù)在提升用戶賬號支付額度時會造成支付請求發(fā)送中斷的問題。

本申請實(shí)施例采用下述技術(shù)方案：

一種請求發(fā)送方法，包括：

基于用戶賬號向服務(wù)器發(fā)送操作請求；

接收服務(wù)器根據(jù)所述操作請求返回的操作結(jié)果；

當(dāng)操作結(jié)果為所述用戶賬號的操作權(quán)限與所述操作請求不匹配時，保存所述操作請求，并向所述服務(wù)器發(fā)送操作權(quán)限提升請求；

在所述用戶賬號的操作權(quán)限提升后，向所述服務(wù)器發(fā)送保存的操作請求。

一種支付請求發(fā)送方法，包括：

基于用戶賬號向服務(wù)器發(fā)送支付請求；

接收服務(wù)器根據(jù)所述支付請求返回的支付結(jié)果；

當(dāng)支付結(jié)果為所述用戶賬號的支付額度與所述支付請求所要支付的金額不匹配時，保存所述支付請求，并向服務(wù)器發(fā)送支付額度提升請求；

在所述用戶賬號的支付額度提升后，向所述服務(wù)器發(fā)送保存的支付請求。

一種請求發(fā)送裝置，包括：

請求發(fā)送第一單元，用于基于用戶賬號向服務(wù)器發(fā)送操作請求；

操作結(jié)果接收單元，用于接收服務(wù)器根據(jù)所述操作請求返回的操作結(jié)果；

權(quán)限提升請求發(fā)送單元，用于當(dāng)操作結(jié)果接收單元接收到的操作結(jié)果為所述用戶賬號的操作權(quán)限與所述操作請求不匹配時，保存所述操作請求，并向所述服務(wù)器發(fā)送操作權(quán)限提升請求；

請求發(fā)送第二單元，在所述用戶賬號的操作權(quán)限提升后，向所述服務(wù)器發(fā)送保存的操作請求。

一種支付請求發(fā)送裝置，包括：

支付請求第一發(fā)送單元，用于基于用戶賬號向服務(wù)器發(fā)送支付請求；

支付結(jié)果接收單元，用于接收服務(wù)器根據(jù)所述支付請求返回的支付結(jié)果；

支付額度提升請求發(fā)送單元，用于當(dāng)支付結(jié)果接收單元接收到的支付結(jié)果為所述用戶賬號的支付額度與所述支付請求所要支付的金額不匹配時，保存所述支付請求，并向服務(wù)器發(fā)送支付額度提升請求；

支付請求第二發(fā)送單元，用于在所述用戶賬號的支付額度提升后，向所述服務(wù)器發(fā)送保存的支付請求。

本申請實(shí)施例采用的上述至少一個技術(shù)方案能夠達(dá)到以下有益效果：

當(dāng)基于用戶賬號向服務(wù)器發(fā)送操作請求后，可以在接收到服務(wù)器根據(jù)所述操作請求返回的操作結(jié)果為所述用戶賬號操作權(quán)限與所述操作請求不匹配時，保存所述操作請求，同時向服務(wù)器發(fā)送操作權(quán)限提升請求，并在所述用戶賬號的操作權(quán)限的提升后，自動向服務(wù)器發(fā)送保存的操作請求，由于在提升用戶賬號權(quán)限后，可以重新自動向服務(wù)器發(fā)送操作請求，而不需要用戶再次輸入所述操作請求，從而保證了操作請求發(fā)送的連續(xù)性。

附圖說明

此處所說明的附圖用來提供對本申請的進(jìn)一步理解，構(gòu)成本申請的一部分，本申請的示意性實(shí)施例及其說明用于解釋本申請，并不構(gòu)成對本申請的不當(dāng)限定。在附圖中：

圖1為本申請實(shí)施例提供的一種請求發(fā)送方法的具體實(shí)現(xiàn)流程示意圖；

圖2為本申請實(shí)施例提供的一種操作結(jié)果展示界面的效果圖；

圖3為本申請實(shí)施例提供的一種包含權(quán)限提升頁面地址的操作結(jié)果展示界面的效果圖；

圖4為本申請實(shí)施例提供的一種權(quán)限提升頁面的效果圖；

圖5為本申請實(shí)施例提供的一種支付請求發(fā)送方法的具體實(shí)現(xiàn)流程示意圖；

圖6為本申請實(shí)施例提供的一種請求發(fā)送裝置的具體結(jié)構(gòu)示意圖；

圖7為本申請實(shí)施例提供的一種支付請求發(fā)送裝置的具體結(jié)構(gòu)示意圖。

具體實(shí)施方式

為使本申請的目的、技術(shù)方案和優(yōu)點(diǎn)更加清楚，下面將結(jié)合本申請具體實(shí)施例及相應(yīng)的附圖對本申請技術(shù)方案進(jìn)行清楚、完整地描述。顯然，所描述的實(shí)施例僅是本申請一部分實(shí)施例，而不是全部的實(shí)施例?；诒旧暾堉械膶?shí)施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實(shí)施例，都屬于本申請保護(hù)的范圍。

以下結(jié)合附圖，詳細(xì)說明本申請各實(shí)施例提供的技術(shù)方案。

本申請實(shí)施例提供的請求發(fā)送方法的執(zhí)行主體，可以但不限于為手機(jī)、平板電腦、個人電腦(Personal Computer，PC)、智能電視以及任何可以運(yùn)行應(yīng)用(Application，APP)的終端設(shè)備中的至少一種。此外，該方法的執(zhí)行主體，也可以是APP本身。

為便于描述，下文以該方法的執(zhí)行主體為閱讀APP為例，對該方法的實(shí)施方式進(jìn)行介紹?？梢岳斫?，該方法的執(zhí)行主體為閱讀APP只是一種示例性的說明，并不應(yīng)理解為對該方法的限定。

本申請實(shí)施例提供了一種請求發(fā)送方法，用以解決現(xiàn)有技術(shù)在提升用戶賬號權(quán)限時會造成請求發(fā)送中斷的問題。該方法的具體實(shí)現(xiàn)流程示意圖如圖1所示，可以包括下述步驟：

步驟11，基于用戶賬號向服務(wù)器發(fā)送操作請求；

所述用戶賬號可以是指用戶在閱讀APP上主動注冊的賬號，例如用戶主動注冊的漫畫閱讀APP賬號或者文本閱讀APP賬號等等；或者也可以是閱讀APP根據(jù)用戶的行為而自動創(chuàng)建的賬號，例如，假設(shè)用戶A沒有在閱讀APP上注冊過用戶賬號，當(dāng)用戶A啟動該閱讀APP時，該閱讀APP可以自動為用戶A創(chuàng)建賬號(比如，根據(jù)用戶A所使用的終端設(shè)備的設(shè)備號，為用戶A創(chuàng)建與該設(shè)備號對應(yīng)的用戶賬號)。

后續(xù)用戶往往首先需要通過用戶賬號登錄該閱讀APP，進(jìn)而使用該閱讀APP進(jìn)行閱讀。

則所述基于用戶賬號向服務(wù)器發(fā)送操作請求，可以是指用戶在通過用戶賬號登錄該閱讀APP后，通過指定操作觸發(fā)該閱讀APP向服務(wù)器發(fā)送的操作請求。

步驟12，接收服務(wù)器根據(jù)所述操作請求返回的操作結(jié)果；

一般地，服務(wù)器可以對不同的用戶賬號進(jìn)行操作權(quán)限分級，用戶賬號的操作權(quán)限等級越高，通過該用戶賬號登錄閱讀APP后可以閱讀的內(nèi)容也就越豐富，反之，用戶賬號的操作權(quán)限等級越低，則通過該用戶賬號登錄閱讀APP后可以閱讀的內(nèi)容也較少。

為了避免基于用戶賬號向服務(wù)器發(fā)送的操作請求與用戶賬號的操作權(quán)限不匹配的問題，在一種實(shí)施方式中，服務(wù)器在接收到基于用戶賬號發(fā)送的操作請求后，首先將會對發(fā)送操作請求的用戶賬號的操作權(quán)限進(jìn)行查詢，當(dāng)查詢結(jié)果為用戶賬號的操作權(quán)限與基于該用戶賬號發(fā)送的操作請求匹配時，服務(wù)器可以根據(jù)操作請求執(zhí)行操作并向閱讀APP返回操作結(jié)果。而當(dāng)查詢結(jié)果為用戶賬號的操作權(quán)限與基于該用戶賬號發(fā)送的操作請求不匹配時，服務(wù)器將不執(zhí)行所述操作請求對應(yīng)的操作，并向閱讀APP返回操作結(jié)果，當(dāng)閱讀APP接收到的操作結(jié)果為用戶賬號的操作權(quán)限與所述操作請求不匹配時，后續(xù)該閱讀APP將執(zhí)行步驟13。

例如，閱讀APP的服務(wù)器可以將用戶賬號的操作權(quán)限等級劃分成a、b、c三個等級，通過權(quán)限等級為a級的用戶賬號可以閱讀D類、E類以及F類的書籍，通過權(quán)限等級為b級的用戶賬號可以閱讀D類以及E類的書籍，而通過權(quán)限等級為c級的用戶賬號僅可以閱讀D類的書籍，在這種情況下，當(dāng)用戶賬號權(quán)限等級為c級的用戶向服務(wù)器發(fā)送針對E類書籍的閱讀請求時，服務(wù)器對該用戶賬號的操作權(quán)限進(jìn)行查詢，確定該用戶賬號不具備閱讀E類書籍的權(quán)限，服務(wù)器將不會執(zhí)行所述操作請求對應(yīng)的操作，并向該閱讀APP返回操作禁止執(zhí)行的操作結(jié)果，閱讀APP接收到該操作結(jié)果后，可以通過如圖2所示的界面，向用戶展示操作結(jié)果以及造成該操作禁止執(zhí)行的原因。

步驟13，當(dāng)通過執(zhí)行步驟12接收到的操作結(jié)果為所述用戶賬號的操作權(quán)限與所述操作請求不匹配時，保存所述操作請求，并向所述服務(wù)器發(fā)送操作權(quán)限提升請求；

一般地，APP往往是通過該APP的軟件開發(fā)工具包(Software Development Kit，SDK)來實(shí)現(xiàn)該APP的相關(guān)功能，其中，所述SDK可以是為指定APP的功能實(shí)現(xiàn)而創(chuàng)建的軟件框架、操作系統(tǒng)、應(yīng)用程序編程接口API等工具的集合。例如，閱讀APP可以通過該APP的SDK中用于發(fā)送操作請求的SDK，向服務(wù)器發(fā)送閱讀請求。

則當(dāng)通過執(zhí)行步驟12接收到的操作結(jié)果為所述用戶賬號的操作權(quán)限與所述操作請求不匹配時，保存所述操作請求，具體可以包括：通過用于發(fā)送所述操作請求的軟件開發(fā)工具包SDK保存所述操作請求。

需要說明的是，通過SDK保存所述操作請求僅為一種實(shí)施方式，除此之外，本申請實(shí)施例還可以采用其他方式對操作請求進(jìn)行保存，比如，還可以通過該閱讀APP所對應(yīng)的緩存來保存所述操作請求。針對如何保存所述操作請求本申請實(shí)施例不做限定。

當(dāng)操作結(jié)果為所述用戶賬號的操作權(quán)限與所述操作請求不匹配時，用戶可以向服務(wù)器發(fā)送操作權(quán)限提升請求，仍以閱讀APP為例，用戶可以通過瀏覽器登錄該閱讀APP的網(wǎng)站，并通過該網(wǎng)站訪問操作權(quán)限提升頁面，通過該頁面向閱讀APP的服務(wù)器發(fā)送操作權(quán)限提升請求。

為了方便用戶打開操作權(quán)限提升頁面，并通過權(quán)限等級提升頁面向服務(wù)器發(fā)送操作權(quán)限提升請求的操作，在一種實(shí)施方式中，APP接收到的服務(wù)器返回的操作結(jié)果中，往往包含有操作權(quán)限提升頁面的地址，該地址比如可以為統(tǒng)一資源定位符號(Uniform Resource Locator，URL)，即用于鏈接操作權(quán)限提升頁面的網(wǎng)址鏈接，則向服務(wù)器發(fā)送操作權(quán)限提升請求，具體可以包括：根據(jù)所述操作結(jié)果中包含的操作權(quán)限提升頁面的地址，向所述服務(wù)器發(fā)送操作權(quán)限提升請求。

例如，如圖3所示，包含操作權(quán)限提升頁面的地址的操作結(jié)果，其中，帶有下劃線的網(wǎng)址“www.quanxiantishe.com”為操作權(quán)限提升頁面的地址。

需要說明的是，所述權(quán)限等級提升頁面一般為超文本標(biāo)記語言(HyperText Markup Language，HTML)頁面，且目前常用的是第五版本HTML，即HTML5。

一般地，HTML5頁面一般是通過HTLM5容器來加載的，為了加載所述操作權(quán)限提升HTML5頁面，需要調(diào)用HTML5容器。

在一種實(shí)施方式中，根據(jù)所述操作結(jié)果中包含的操作權(quán)限提升頁面的地址，向所述服務(wù)器發(fā)送操作權(quán)限提升請求，具體可以包括：調(diào)用超文本標(biāo)記語言HTML容器；通過所述HTML容器，根據(jù)所述URL，向所述服務(wù)器發(fā)送操作權(quán)限提升頁面的訪問請求；加載所述服務(wù)器根據(jù)所述訪問請求返回的操作權(quán)限提升頁面；通過所述操作權(quán)限提升頁面，向所述服務(wù)器發(fā)送操作權(quán)限提升請求。

步驟14，在所述用戶賬號的操作權(quán)限提升后，向所述服務(wù)器發(fā)送保存的操作請求。

需要說明的是，閱讀APP往往與該閱讀APP的服務(wù)器建立實(shí)時通信連接，以便閱讀APP能夠?qū)崟r從服務(wù)器獲得當(dāng)前登錄該閱讀APP的用戶賬號的信息變更，則當(dāng)閱讀APP從服務(wù)器獲得有關(guān)所述用戶賬號操作權(quán)限提升的信息后，該閱讀APP可以再次向服務(wù)器發(fā)送保存的操作請求。

例如，當(dāng)服務(wù)器接收到閱讀APP發(fā)送的操作權(quán)限提升請求，并響應(yīng)于該操作權(quán)限提升請求對用戶賬號操作權(quán)限等級進(jìn)行提升后，服務(wù)器可以向該閱讀APP返回用戶賬號操作權(quán)限等級提升完成通知，閱讀APP在接收到服務(wù)器返回的用戶賬號操作權(quán)限等級提升完成通知后，即可以向服務(wù)器發(fā)送保存的操作請求。在這種情況下，用戶使用終端當(dāng)前所顯示的頁面可能仍為操作權(quán)限提升頁面，由于操作權(quán)限提升頁面上無法顯示閱讀APP已經(jīng)向服務(wù)器重新發(fā)送操作請求的相關(guān)信息，這就可能造成用戶無法確認(rèn)閱讀APP是否已經(jīng)重新向服務(wù)器發(fā)送了保存的操作請求，進(jìn)而可能造成用戶通過閱讀APP重復(fù)發(fā)送操作請求。

為了避免上述問題，在一種實(shí)施方式中，在用戶通過操作權(quán)限提升HTML5頁面向服務(wù)器發(fā)送操作權(quán)限提升請求后，加載該操作權(quán)限提升HTML5頁面的HTLM5容器可以回調(diào)閱讀APP，以使得在發(fā)送操作權(quán)限提升請求后，終端可以重新顯示閱讀APP，則步驟13的具體實(shí)現(xiàn)方式可以包括：通過所述HTML容器回調(diào)所述閱讀APP中保存操作請求的SDK；并通過所述SDK向所述服務(wù)器發(fā)送保存的操作請求。

為了保證HTML容器可以回調(diào)到閱讀APP的SDK，在閱讀APP調(diào)用HTML容器時，將建立閱讀APP中用于發(fā)送操作請求的SDK與該HTML容器的對應(yīng)關(guān)系，同時，該SDK將向所述HTML容器發(fā)送回調(diào)條件，以使得在滿足所述回調(diào)條件時，HTML容器根據(jù)預(yù)先建立的對應(yīng)關(guān)系，回調(diào)SDK。

其中，所述回調(diào)條件，比如可以是當(dāng)HTML容器接收到用戶輸入的指定操作指令而觸發(fā)的，例如，如圖4所述，當(dāng)HTML容器接收到用戶通過點(diǎn)擊“提交”按鍵，而輸入的操作權(quán)限提升請求提交指令后，HTML容器接收到所述提交指令可以視為滿足所述回調(diào)條件，HTML容器將向服務(wù)器發(fā)送操作權(quán)限提升請求，同時將根據(jù)預(yù)先設(shè)置的對應(yīng)關(guān)系，回調(diào)SDK，當(dāng)閱讀APP中用于保存操作請求的SDK被HTML容器回調(diào)后，閱讀APP可以視為所述用戶賬號操作權(quán)限提升完成，并通過所述SDK向服務(wù)器發(fā)送保存的操作請求。

以上為本申請實(shí)施例提供的一種請求發(fā)送方法的具體實(shí)現(xiàn)方式，下面將以購物APP為例，具體介紹在使用該購物APP時的一種支付請求發(fā)送方法，該方法的具體實(shí)現(xiàn)流程示意圖如圖5所示，主要包括下述步驟：

步驟21，基于用戶賬號向服務(wù)器發(fā)送支付請求；

用戶通過用戶賬號登錄購物APP，進(jìn)而使用該購物APP進(jìn)行商品購買，當(dāng)用戶在購物APP上選擇好期望購買的商品后，用戶通過點(diǎn)擊“付款”按鍵，或者其他操作，進(jìn)而觸發(fā)該購物APP向服務(wù)器發(fā)送支付請求。

步驟22，接收服務(wù)器根據(jù)所述支付請求返回的支付結(jié)果；

一般地，服務(wù)器可以對不同的用戶賬號進(jìn)行支付額度分級，用戶賬號的支付額度越高，用戶通過該用戶賬號登錄購物APP后可以使用的支付金額也就越高，反之，用戶賬號的支付額度越低，則用戶通過該用戶賬號登錄購物APP后可以使用的支付金額也就越少。

為了避免基于用戶賬號向服務(wù)器發(fā)送的支付請求與用戶賬號的支付額度不匹配的問題，在一種實(shí)施方式中，服務(wù)器在接收到基于用戶賬號發(fā)送的支付請求后，首先將會對發(fā)送操作請求的用戶賬號的支付額度進(jìn)行查詢，當(dāng)查詢結(jié)果為用戶賬號的支付額度大于基于該用戶賬號發(fā)送的支付請求所要求支付的金額時，服務(wù)器可以根據(jù)支付請求執(zhí)行支付操作并向購物APP返回支付結(jié)果。而當(dāng)查詢結(jié)果為用戶賬號的支付額度小于基于該用戶賬號發(fā)送的支付請求所要求支付的金額時，服務(wù)器將無法完成支付操作，并向購物APP返回支付結(jié)果，當(dāng)支付APP接收到的操作結(jié)果為用戶賬號的支付額度小于支付請求所要求支付的金額時，為了完成此次交易，用戶可能需要通過購物APP提升當(dāng)前用戶賬號的支付額度，具體提升支付額度的方式詳見步驟13。

步驟23，保存所述支付請求，并向服務(wù)器發(fā)送支付額度提升請求；

其中，一般通過用于發(fā)送所述支付請求的軟件開發(fā)工具包SDK保存所述支付請求。

需要說明的是，通過SDK保存所述支付請求僅為一種實(shí)施方式，除此之外，本申請實(shí)施例還可以采用其他方式對支付請求進(jìn)行保存，比如，還可以通過該購物APP所對應(yīng)的緩存來保存所述支付請求。針對如何保存所述支付請求本申請實(shí)施例不做限定。

為了方便用戶打開支付額度提升頁面，并通過支付額度提升頁面向服務(wù)器發(fā)送支付額度提升請求的操作，在一種實(shí)施方式中，購物APP接收到的服務(wù)器返回的支付結(jié)果中，往往包含有支付額度提升頁面的地址，該地址比如可以為統(tǒng)一資源定位符號(Uniform Resource Locator，URL)，即用于鏈接支付額度提升頁面的網(wǎng)址鏈接，則向服務(wù)器發(fā)送支付額度提升請求，具體可以包括：根據(jù)所述支付結(jié)果中包含的操作權(quán)限提升頁面的地址，向所述服務(wù)器發(fā)送操作權(quán)限提升請求。

需要說明的是，所述支付額度提升頁面一般為HTML5頁面，而HTML5頁面一般是通過HTLM5容器來加載的，因而為了加載所述操作權(quán)限提升HTML5頁面，需要調(diào)用HTML5容器。

在一種實(shí)施方式中，根據(jù)所述支付結(jié)果中包含的支付額度提升頁面的地址，向所述服務(wù)器發(fā)送操作權(quán)限提升請求，具體可以包括：調(diào)用HTML容器；通過所述HTML容器，根據(jù)所述URL，向所述服務(wù)器發(fā)送支付額度提升頁面的訪問請求；加載所述服務(wù)器根據(jù)所述訪問請求返回的支付額度提升頁面；通過所述支付額度提升頁面，向所述服務(wù)器發(fā)送支付額度提升請求。

步驟24，在所述用戶賬號的支付額度提升后，向所述服務(wù)器發(fā)送保存的支付請求。

在一種實(shí)施方式中，在用戶通過支付額度提升HTML5頁面向服務(wù)器發(fā)送支付額度提升請求后，加載該支付額度提升HTML5頁面的HTLM5容器可以回調(diào)閱讀APP，以使得在發(fā)送支付額度提升請求后，終端可以重新喚起購物APP，并展示購物APP的支付界面，則步驟13的具體實(shí)現(xiàn)方式可以包括：通過所述HTML容器回調(diào)所述購物APP中保存支付請求的SDK；并通過所述SDK向服務(wù)器發(fā)送保存的支付請求。

在購物APP調(diào)用HTML容器時，將建立購物APP中用于發(fā)送支付請求的SDK與該HTML容器的對應(yīng)關(guān)系，同時，該SDK將向所述HTML容器發(fā)送回調(diào)條件，以使得在滿足所述回調(diào)條件時，HTML容器根據(jù)預(yù)先建立的對應(yīng)關(guān)系，回調(diào)SDK。

其中，所述回調(diào)條件，比如可以是當(dāng)HTML容器接收到用戶輸入的指定操作指令而觸發(fā)的，例如，當(dāng)HTML容器接收到用戶通過點(diǎn)擊“提交”按鍵，而輸入的支付額度提升請求提交指令后，HTML容器接收到所述提交指令可以視為滿足所述回調(diào)條件，HTML容器將向服務(wù)器發(fā)送支付額度提升請求，同時將根據(jù)預(yù)先設(shè)置的對應(yīng)關(guān)系，回調(diào)SDK，當(dāng)購物APP中用于保存支付請求的SDK被HTML容器回調(diào)后，閱讀APP可以視為所述用戶賬號的支付額度提升完成，并通過所述SDK向服務(wù)器發(fā)送保存的支付請求，此時服務(wù)器會根據(jù)接收到的支付請求，再次查詢發(fā)送該支付請求的用戶賬號的支付額度，當(dāng)服務(wù)器查詢到該賬號的支付額度已經(jīng)提升后，則服務(wù)器根據(jù)接收到的支付請求，執(zhí)行支付操作，并向購物APP返回支付成功結(jié)果。

本申請實(shí)施例還提供了一種請求發(fā)送裝置，用以解決現(xiàn)有技術(shù)在提升用戶賬號權(quán)限時會造成請求發(fā)送中斷的問題。該裝置的具體結(jié)構(gòu)示意圖如圖6所示，包括：請求發(fā)送第一單元31，操作結(jié)果接收單元32、權(quán)限提升請求發(fā)送單元33以及請求發(fā)送第二單元34。

其中，請求發(fā)送第一單元31，用于基于用戶賬號向服務(wù)器發(fā)送操作請求；

操作結(jié)果接收單元32，用于接收服務(wù)器根據(jù)所述操作請求返回的操作結(jié)果；

權(quán)限提升請求發(fā)送單元33，用于當(dāng)操作結(jié)果接收單元32接收到的操作結(jié)果為所述用戶賬號的操作權(quán)限與所述操作請求不匹配時，保存所述操作請求，并向所述服務(wù)器發(fā)送操作權(quán)限提升請求；

請求發(fā)送第二單元34，在所述用戶賬號的操作權(quán)限提升后，向所述服務(wù)器發(fā)送保存的操作請求。

在一種實(shí)施方式中，權(quán)限提升請求發(fā)送單元33，具體用于：根據(jù)所述操作結(jié)果中包含的操作權(quán)限提升頁面的地址，向所述服務(wù)器發(fā)送操作權(quán)限提升請求。

在一種實(shí)施方式中，所述地址為統(tǒng)一資源定位符URL，則權(quán)限提升請求發(fā)送單元33，具體用于：調(diào)用超文本標(biāo)記語言HTML容器；通過所述HTML容器，根據(jù)所述URL，向所述服務(wù)器發(fā)送操作權(quán)限提升頁面的訪問請求；加載所述服務(wù)器根據(jù)所述訪問請求返回的操作權(quán)限提升頁面；通過所述操作權(quán)限提升頁面，向所述服務(wù)器發(fā)送操作權(quán)限提升請求。

在一種實(shí)施方式中，權(quán)限提升請求發(fā)送單元33，具體用于：通過用于發(fā)送所述操作請求的軟件開發(fā)工具包SDK保存所述操作請求。

在一種實(shí)施方式中，權(quán)限提升請求發(fā)送單元33，具體用于：調(diào)用所述HTML容器；建立所述SDK與所述HTML容器的對應(yīng)關(guān)系；確定所述HTML容器回調(diào)所述SDK的回調(diào)條件。

在一種實(shí)施方式中，請求發(fā)送第二單元34，具體用于：當(dāng)滿足所述回調(diào)條件時，根據(jù)所述對應(yīng)關(guān)系，通過所述HTML容器回調(diào)所述SDK；通過所述SDK向所述服務(wù)器發(fā)送保存的操作請求。

本申請實(shí)施例還提供了一種支付請求發(fā)送裝置，用以解決現(xiàn)有技術(shù)在提升用戶賬號支付額度時會造成支付請求發(fā)送中斷的問題。該裝置的具體結(jié)構(gòu)示意圖如圖7所示，包括：支付請求發(fā)送第一單元41，支付結(jié)果接收單元42、支付額度提升請求發(fā)送單元43以及支付請求發(fā)送第二單元44。

其中，支付請求發(fā)送第一單元41，用于基于用戶賬號向服務(wù)器發(fā)送支付請求；

支付結(jié)果接收單元42，用于接收服務(wù)器根據(jù)所述支付請求返回的支付結(jié)果；

支付額度提升請求發(fā)送單元43，用于當(dāng)支付結(jié)果接收單元42接收到的支付結(jié)果為所述用戶賬號的支付額度與所述支付請求所要支付的金額不匹配時，保存所述支付請求，并向所述服務(wù)器發(fā)送支付額度提升請求；

支付請求發(fā)送第二單元44，在所述用戶賬號的支付額度提升后，向所述服務(wù)器發(fā)送保存的支付請求。

在一種實(shí)施方式中，支付額度提升請求發(fā)送單元43，具體用于：根據(jù)所述支付結(jié)果中包含的支付額度提升頁面的地址，向所述服務(wù)器發(fā)送支付額度提升請求。

在一種實(shí)施方式中，所述地址為統(tǒng)一資源定位符URL，則支付額度提升請求發(fā)送單元43，具體用于：調(diào)用超文本標(biāo)記語言HTML容器；通過所述HTML容器，根據(jù)所述URL，向所述服務(wù)器發(fā)送支付額度提升頁面的訪問請求；加載所述服務(wù)器根據(jù)所述訪問請求返回的支付額度提升頁面；通過所述支付額度提升頁面，向所述服務(wù)器發(fā)送支付額度提升請求。

在一種實(shí)施方式中，支付額度提升請求發(fā)送單元43，具體用于：通過用于發(fā)送所述支付請求的軟件開發(fā)工具包SDK保存所述支付請求。

在一種實(shí)施方式中，支付額度提升請求發(fā)送單元43，具體用于：調(diào)用所述HTML容器；建立所述SDK與所述HTML容器的對應(yīng)關(guān)系；確定所述HTML容器回調(diào)所述SDK的回調(diào)條件。

在一種實(shí)施方式中，支付請求發(fā)送第二單元44，具體用于：當(dāng)滿足所述回調(diào)條件時，根據(jù)所述對應(yīng)關(guān)系，通過所述HTML容器回調(diào)所述SDK；通過所述SDK向所述服務(wù)器發(fā)送保存的支付請求。

采用本申請實(shí)施例提供的請求發(fā)送方法，當(dāng)基于用戶賬號向服務(wù)器發(fā)送操作請求后，可以在接收到服務(wù)器根據(jù)所述操作請求返回的操作結(jié)果為所述用戶賬號操作權(quán)限與所述操作請求不匹配時，保存所述操作請求，同時向服務(wù)器發(fā)送操作權(quán)限提升請求，并在所述用戶賬號的操作權(quán)限的提升后，自動向服務(wù)器發(fā)送保存的操作請求，由于在提升用戶賬號權(quán)限后，可以重新自動向服務(wù)器發(fā)送操作請求，而不需要用戶再次輸入所述操作請求，從而保證了操作請求發(fā)送的連續(xù)性。

本領(lǐng)域內(nèi)的技術(shù)人員應(yīng)明白，本發(fā)明的實(shí)施例可提供為方法、系統(tǒng)、或計(jì)算機(jī)程序產(chǎn)品。因此，本發(fā)明可采用完全硬件實(shí)施例、完全軟件實(shí)施例、或結(jié)合軟件和硬件方面的實(shí)施例的形式。而且，本發(fā)明可采用在一個或多個其中包含有計(jì)算機(jī)可用程序代碼的計(jì)算機(jī)可用存儲介質(zhì)(包括但不限于磁盤存儲器、CD-ROM、光學(xué)存儲器等)上實(shí)施的計(jì)算機(jī)程序產(chǎn)品的形式。

本發(fā)明是參照根據(jù)本發(fā)明實(shí)施例的方法、設(shè)備(系統(tǒng))、和計(jì)算機(jī)程序產(chǎn)品的流程圖和/或方框圖來描述的。應(yīng)理解可由計(jì)算機(jī)程序指令實(shí)現(xiàn)流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結(jié)合?？商峁┻@些計(jì)算機(jī)程序指令到通用計(jì)算機(jī)、專用計(jì)算機(jī)、嵌入式處理機(jī)或其他可編程數(shù)據(jù)處理設(shè)備的處理器以產(chǎn)生一個機(jī)器，使得通過計(jì)算機(jī)或其他可編程數(shù)據(jù)處理設(shè)備的處理器執(zhí)行的指令產(chǎn)生用于實(shí)現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的裝置。

這些計(jì)算機(jī)程序指令也可存儲在能引導(dǎo)計(jì)算機(jī)或其他可編程數(shù)據(jù)處理設(shè)備以特定方式工作的計(jì)算機(jī)可讀存儲器中，使得存儲在該計(jì)算機(jī)可讀存儲器中的指令產(chǎn)生包括指令裝置的制造品，該指令裝置實(shí)現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。

這些計(jì)算機(jī)程序指令也可裝載到計(jì)算機(jī)或其他可編程數(shù)據(jù)處理設(shè)備上，使得在計(jì)算機(jī)或其他可編程設(shè)備上執(zhí)行一系列操作步驟以產(chǎn)生計(jì)算機(jī)實(shí)現(xiàn)的處理，從而在計(jì)算機(jī)或其他可編程設(shè)備上執(zhí)行的指令提供用于實(shí)現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。

在一個典型的配置中，計(jì)算設(shè)備包括一個或多個處理器(CPU)、輸入/輸出接口、網(wǎng)絡(luò)接口和內(nèi)存。

內(nèi)存可能包括計(jì)算機(jī)可讀介質(zhì)中的非永久性存儲器，隨機(jī)存取存儲器(RAM)和/或非易失性內(nèi)存等形式，如只讀存儲器(ROM)或閃存(flash RAM)。內(nèi)存是計(jì)算機(jī)可讀介質(zhì)的示例。

計(jì)算機(jī)可讀介質(zhì)包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術(shù)來實(shí)現(xiàn)信息存儲。信息可以是計(jì)算機(jī)可讀指令、數(shù)據(jù)結(jié)構(gòu)、程序的模塊或其他數(shù)據(jù)。計(jì)算機(jī)的存儲介質(zhì)的例子包括，但不限于相變內(nèi)存(PRAM)、靜態(tài)隨機(jī)存取存儲器(SRAM)、動態(tài)隨機(jī)存取存儲器(DRAM)、其他類型的隨機(jī)存取存儲器(RAM)、只讀存儲器(ROM)、電可擦除可編程只讀存儲器(EEPROM)、快閃記憶體或其他內(nèi)存技術(shù)、只讀光盤只讀存儲器(CD-ROM)、數(shù)字多功能光盤(DVD)或其他光學(xué)存儲、磁盒式磁帶，磁帶磁磁盤存儲或其他磁性存儲設(shè)備或任何其他非傳輸介質(zhì)，可用于存儲可以被計(jì)算設(shè)備訪問的信息。按照本文中的界定，計(jì)算機(jī)可讀介質(zhì)不包括暫存電腦可讀媒體(transitory media)，如調(diào)制的數(shù)據(jù)信號和載波。

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

本領(lǐng)域技術(shù)人員應(yīng)明白，本申請的實(shí)施例可提供為方法、系統(tǒng)或計(jì)算機(jī)程序產(chǎn)品。因此，本申請可采用完全硬件實(shí)施例、完全軟件實(shí)施例或結(jié)合軟件和硬件方面的實(shí)施例的形式。而且，本申請可采用在一個或多個其中包含有計(jì)算機(jī)可用程序代碼的計(jì)算機(jī)可用存儲介質(zhì)(包括但不限于磁盤存儲器、CD-ROM、光學(xué)存儲器等)上實(shí)施的計(jì)算機(jī)程序產(chǎn)品的形式。

以上所述僅為本申請的實(shí)施例而已，并不用于限制本申請。對于本領(lǐng)域技術(shù)人員來說，本申請可以有各種更改和變化。凡在本申請的精神和原理之內(nèi)所作的任何修改、等同替換、改進(jìn)等，均應(yīng)包含在本申請的權(quán)利要求范圍之內(nèi)。