201209619 六、發明說明 一種基於開放應用編程介面實現網路業務的方法、系 統及裝置。 【發明所屬之技術領域】 本發明關於網路通信技術領域，尤其關於一種基於開 放應用編程介面實現網路業務的方法、系統及裝置。 【先前技術】201209619 VI. Description of the Invention A method, system and device for implementing network services based on an open application programming interface. [Technical Field] The present invention relates to the field of network communication technologies, and more particularly to a method, system and apparatus for implementing network services based on an open application programming interface. [Prior Art]
Open API ( Open- Application Programming Interface ’開放應用編程介面）是SaaS( Software as a Service， 軟體即服務）模式下常見的一種應用介面，ISP ( Internet Service Provider，網際網路服務提供商）將其可提供的網 站服務分別封裝成一系列的API，開放給第三方開發者， 例如，ISV ( Independent Software Vendor，獨立軟體供應 商），ISV可通過其ISV伺服器使用相應的業務，該方式 稱爲開放網站的API，所開放的API稱爲Open API。 ISP對外提供Open API後，吸引了更多ISV基於 ISV提供的Open API開發更多的應用，從而使得ISV能 夠獲得更多的流量與市場份額，並且，對於ISV而言， ISV伺服器也不需要龐大的硬體與技術投資就可以輕鬆快 捷的使用符合其要求的業務，從而減少了投資成本。因 此，Open API作爲網際網路在線服務的發展基礎，已經 成爲越來越多網際網路企業發展服務的選擇，在網路業務 -5- 201209619 中具有很大的發展空間。 基於Open API的應用前景，各大國內外網站的ISP 都推出了自己的Open API網站（即基於Open API實現網 路業務的網站）。目前普遍使用的Open API爲基於REST 介面形式的 Open API，稱之爲REST API。基於REST API實現網路業務時，通過Internet (網際網路）採用 HTTP GET的方式向業務實現伺服器發送REST服務，業 務實現伺服器採用POST的方式回應REST服務，其中， 業務實現伺服器以XML、Jason等結構化資料作爲返回結 果回應REST服務。 上述基於REST API實現網路業務的方案存在很多方 面的不足，首先，以結構化資料形式作爲返回結果，ISV 獲取資料比較容易，而一般業務實現伺服器提供的業務資 料都不希望被用戶以外的第三方即ISV獲得，因此，基於 上述方式實現的網路業務，對於業務實現伺服器而言，資 料安全性低；並且，目前大部分網路業務都包含複雜業務 邏輯的操作，通常需要用戶和服務端之間進行多次交互操 作，而以上實現網路業務的方法中，一個REST API只能 實現用戶和服務端之間的單次交互，例如查詢、更新資料 等。因此，對於複雜網路業務，IS V需要構建多個REST API才能實現一個完整的流程，這使得ISV需要解析多個 API調用間的業務邏輯，非常難於使用，而且不同的ISV 解析能力存在偏差，使得業務一致性很難得到保證，從而 對於業務實現伺服器而言，業務的可控性差。 -6- 201209619 綜上所述，基於現有API實現的網路業務，無法保證 業務資料的安全性，並且業務可控性差。 【發明內容】 有鑒於此，本發明實施例提供一種基於開放應用編程 介面實現網路業務的方法、系統及裝置，用於解決基於現 有技術實現網路業務時，業務資料安全性低以及業務可控 性差的問題。 本發明實施例通過如下技術方案實現： 根據本發明實施例的一個方面，提供了 一種基於開放 應用編程介面實現網路業務的方法，包括： 接收第三方開發伺服器根據用戶的業務請求發送的對 開放應用編程介面Open API的調用請求； 確定所述調用請求中請求調用的Open API對應的網 際網路服務提供商ISP伺服器，並將所述調用請求發送到 確定的所述IS P伺服器； 接收所述ISP伺服器根據所述調用請求返回的服務頁 面，並 將所述服務頁面發送到所述第三方開發伺服器，由所 述第三方開發伺服器對所述服務頁面進行處理後發送給所 述用戶’所述處理爲將所述服務頁面封裝在所述業務請求 對應的頁面中。 根據本發明實施例的另一個方面，還提供了一種基於 開放應用編程介面實現網路業務的裝置，包括： 201209619 第一接收單元，用於接收第三方開發伺服器根據用戶 的業務請求發送的對開放應用編程介面Open API的調用 請求； 第一 ISP調用單元，用於確定所述第一接收單元接收 的調用請求中請求調用的Open API對應的網際網路服務 提供商ISP伺服器，並將所述調用請求發送到所述isp確 定單元確定的所述ISP伺服器； 第一調用結果反饋單元，用於接收所述ISP伺服器根 據所述第一 ISP調用單元發送的調用請求返回的服務頁 面，並將所述服務頁面發送到所述第三方開發伺服器，由 所述第三方開發伺服器對所述服務頁面進行處理後發送給 所述用戶，所述處理爲將所述服務頁面封裝在所述業務請 求對應的頁面中。 根據本發明實施例的另一個方面，還提供了一種基於 開放應用編程介面實現網路業務的系統，包括： 第三方開發伺服器、業務實現伺服器以及ISP伺服 器；其中， 第三方開發伺服器，用於根據用戶的業務請求向業務 實現伺服器發送對開放應用編程介面Open API的調用請 求；以及，接收所述業務實現伺服器返回的服務頁面，並 將所述服務頁面封裝在所述業務請求對應的頁面中發送給 所述用戶； 業務實現伺服器，用於根據所述第三方開發伺服器發 送的調用請求，確定所述調用請求中請求調用的Open -8 - 201209619 API對應的網際網路服務提供商ISP伺 用請求發送到確定的所述ISP伺服器 ISP伺服器返回的服務頁面，並將所述 述第三方伺服器； ISP伺服器，用於根據所述業務實 用請求返回相應的服務頁面給所述業務 通過本發明實施例提供的上述至少 實現網路業務時，首先接收第三方開發 業務請求發送的對Open API的調用請 求中請求調用的Open API對應的ISP 用請求發送到確定的ISP;進而接收該 返回的服務頁面，並將該服務頁面發送 器，由該第三方開發伺服器對服務頁面 用戶，其中的處理爲將服務頁面封裝在 面中，根據該技術方案，一方面，通過 服務資料返回給第三方開發伺服器，與 服務資料以結構化資料形式返回給第： 比’提高了資料的安全性；另一方面， 具備對業務邏輯分析的功能，所有業務 第三方伺服器以及各IS P之間的伺服器 對業務的可控性。 本發明的其他特徵和優點將在隨後 並且’部分地從說明書中變得顯而易見 發明而瞭解。本發明的目的和其他優點 服器，並將所述調 :以及，接收所述 服務頁面發送給所 現伺服器發送的調 實現伺服器。 一個技術方案，在 伺服器根據用戶的 求，確定該調用請 伺服器，並將該調 ISP根據調用請求 至第三方開發伺服 進行處理後發送給 業務請求對應的頁 服務頁面的形式將 現有技術中直接將 三方開發伺服器相 第三方伺服器無需 的控制都通過介於 實現，從而提高了 的說明書中闡述， ，或者通過實施本 可通過在所寫的說 -9 - 201209619 明書、權利要求書、以及附圖中所特別指出的結構來實現 和獲得。 【實施方式】 爲了給出提高業務資料安全性以及提高業務可控性的 實現方案’本發明實施例提供了一種基於開放應用編程介 面實現網路業務的方法、系統及裝置，該技術方案可以應 用於網路業務的實現過程，既可以實現爲一種方法，也可 以實現爲一種裝置。以下結合說明書附圖對本發明的較佳 實施例進行說明，應當理解，此處所描述的較佳實施例僅 .用於說明和解釋本發明，並不用於限定本發明。並且在不 衝突的情況下’本發明中的實施例及實施例中的特徵可以 相互組合。 根據本發明實施例，首先提供了 一種基於開放應用編 程介面實現網路業務的方法，如圖1所示，該方法主要包 括如下步驟： 步驟1 01、業務實現伺服器接收第三方開發伺服器根 據用戶的業務請求發送的對Open API的調用請求。 步驟1 〇2、業務實現伺服器確定接收的調用請求中請 求調用的Open API對應的ISP，並將該調用請求發送到 確定的ISP伺服器； 步驟103、業務實現伺服器接收ISP伺服器根據調用 請求返回的服務頁面。 步驟1 04、業務實現伺服器將該服務頁面發送到第三 -10- 201209619 方開發伺服器，由該第三方開發伺服器對服務頁面進行處 理後發送給用戶。 該步驟1 04中，第三方開發伺服器對服務頁面進行的 處理具體爲：將該服務頁面封裝在業務請求對應的頁面 中〇 通過上述流程實現網路業務的方法，可以應用於多種 網路環境下，其中的業務實現伺服器可以爲設置在相應網 路環境下的用於對該網路環境下實現的業務進行控制和管 理的伺服器；其中的第三方開發伺服器可以爲獨立軟體供 應商ISV伺服器。 本發明實施例中，若調用請求中請求調用的Open API爲多個，則在將調用請求發送到確定的ISP伺服器之 前，即在執行上述步驟102之前，還進一步執行如下步 驟： 確定多個Open API之間的調用關係。 該多個 Open API之間的調用關係用於表徵該多個 Open API是否存在調用順序，根據本發明實施例，一個 調用請求可以同時調用多個Open API，該多個Open API 可以包括存在調用順序的Open API，也可以包括獨立的 Open API，該獨立的Open API與其他Open API不存在調 用順序。 相應地，在確定多個Open API之間的調用關係後， 圖1所示流程的步驟1 02中，將調用請求發送到確定的 I S P伺服器，具體如圖2所示，包括如下步驟： -11 - 201209619 步驟201、根據多個Open API之間的調用關係確定 多個Open API之間是否存在調用順序，若是，執行步驟 202，若否，執行步驟203。 步驟202、將調用請求發送到存在調用關係的多個 Open API中調用順序爲第一位的Open API對應的ISP伺 服器，然後轉至圖1中的步驟1 03。 步驟203、將調用請求發送到多個Open API分別對 應的ISP伺服器，然後轉至圖1中的步驟103。 本發明實施例中，在調用請求中請求調用的0Pen API爲多個並且該多個Open API之間存在調用順序時， 需要根據業務邏輯進行多次調用，直到調用順序爲最後一 位元的Open API被調用。在根據調用順序進行第一次調 用後，在將服務頁面發送到第三方開發伺服器之前，即在 執行圖1所示流程中的步驟1 〇4之前，還可以進一步執行 如下步驟： 將多個Open API之間的調用順序封裝在服務頁面 中〇 通過上述步驟的執行，將Open API之間的調用順序 封裝在返回給用戶的服務頁面中，用戶可以觸發下一 Open API的調用流程，具體處理過程如圖3所示，包括 如下步驟： 步驟301、業務實現伺服器接收用戶根據服務頁面中 封裝的調用順序觸發的對當前調用的第一Open API之後 的第二Open API的調用請求。 -12- 201209619 步驟3〇2、將該調用請求發送到與第二0Pen API對 應的ISP伺服器。 步驟303、接收第二Open API對應的ISP伺服器根 據該調用請求返回的服務頁面。 步驟304、將該服務頁面發送到第三方開發伺服器’ 由第三方開發伺服器對該服務頁面進行處理後發送給用 戶。 根據圖3所示流程，業務實現伺服器根據用戶觸發的 下一 Open API的調用請求，實現對該調用請求的調用過 程。根據本發明較佳實施例，在用戶觸發下—0Pen API 的調用流程後，還可以支援不同Open API對應的ISP伺 服器之間的互調用，例如，對於涉及多個I S P伺服器交互 的複雜業務，在調用第一 Open API對應的ISP伺服器提 供的業務後，還需要進一步調用第二Open API對應的 ISP伺服器提供的業務，但該第二Open API對應的ISP 伺服器可能只支援特定ISP伺服器的訪問，該特定ISP伺 服器一般爲首次被調用的Open API對應的ISP伺服器， 在該情況下，就需要通過第一 Open API對應的ISP伺服 器調用該第二Open API對應的ISP伺服器，從而實現對 第二Open API對應的ISP伺服器提供的業務的獲取，具 體地’業務實現伺服器根據用戶觸發的下一Open API的 調用請求，實現對該調用請求的調用過程，還可以如圖4 所示，包括如下步驟： 步驟40 1、業務實現伺服器接收用戶根據服務頁面中 -13- 201209619 封裝的調用順序觸發的對當前調用的第一 Open API之後 的第二Open API的調用請求， 步驟402、根據多個〇pen API之間的調用關係確定 調用第二Open API是否需要通過第一Open API，若是， 執行步驟403~步驟404，若否，執行步驟405〜步驟406。 該步驟402中，即第一〇pen API和第二Open API之 間存在互調用關係，第二Open API的調用需要通過第一 Open API來完成。 步驟403、通過第一 Open API對應的ISP伺服器將 該調用請求轉發至第二Open API對應的ISP伺服器。 步驟404、接收第一Open API對應的ISP伺服器返 回的處理後的服務頁面，至此跳轉至步驟407。 該步驟404中，該處理具體爲：第一 Open API對應 的ISP伺服器接收第二〇pen API對應的ISP伺服器返回 的服務頁面，並將接收的該服務頁面封裝在自身的服務頁 面中進行返回。 步驟405、將該調用請求發送到與第二Open API對 應的ISP伺服器。 步驟406、接收第二Open API對應的ISP伺服器根 據該調用請求返回的服務頁面，至此跳轉至步驟407。 步驟407、將該服務頁面發送到第三方開發伺服器， 由第三方開發伺服器對該服務頁面進行處理後發送給用 戶。 本發明實施例中，將ISP返回的服務頁面封裝在業務 -14- 201209619 請求對應的頁面中，具體包括： 將該服務頁面通過嵌入頁面Iframe形式嵌入業務請 求對應的頁面中。 其中’以Iframe形式嵌入的頁面爲iframe元素，可 以理解爲頁面中浮動的框架（FRAME)。frames集合提供對 Iframe內容的訪問許可權，即在具體應用中，可以使用 frames集合讀寫ifranie內包含的元素。Open API (Open-Application Programming Interface) is a common application interface in the SaaS (Software as a Service) mode. ISP (Internet Service Provider) can The provided website services are packaged into a series of APIs, which are open to third-party developers. For example, ISV (Independent Software Vendor), ISVs can use corresponding services through their ISV servers. This method is called open website. The API, the open API is called the Open API. After the ISP provides the Open API, it attracts more ISVs to develop more applications based on the Open API provided by ISV, which enables ISVs to gain more traffic and market share, and ISVs do not need ISVs for ISVs. A huge amount of hardware and technology investment can easily and quickly use the business that meets its requirements, thus reducing investment costs. Therefore, as the basis for the development of Internet services, Open API has become the choice of more and more Internet enterprises to develop services, and has a lot of room for development in the network business -5 201209619. Based on the application prospects of Open API, ISPs of major domestic and foreign websites have launched their own Open API websites (ie websites that implement network services based on Open API). The currently widely used Open API is an Open API based on the REST interface, called the REST API. When the network service is implemented based on the REST API, the REST service is sent to the service implementation server through the Internet (Internet), and the service implementation server responds to the REST service by using the POST method, wherein the service implementation server uses XML. Structured data such as Jason respond to the REST service as a result of the return. The above-mentioned schemes for implementing network services based on the REST API have many shortcomings. First, the structured data form is used as the return result, and the ISV obtains the data relatively easily, while the general business implementation server provides the business data without wishing to be external to the user. The third party is obtained by the ISV. Therefore, the network service implemented in the above manner has low data security for the service implementation server; and most of the current network services include operations of complex business logic, usually requiring users and The server performs multiple interactions. In the above method of implementing network services, a REST API can only implement a single interaction between the user and the server, such as querying and updating data. Therefore, for complex network services, IS V needs to build multiple REST APIs to implement a complete process. This makes ISV need to parse the business logic between multiple API calls, which is very difficult to use, and there are deviations in different ISV resolution capabilities. It is difficult to ensure business consistency, so that the service controllability of the service implementation server is poor. -6- 201209619 In summary, based on the network services implemented by the existing API, the security of the business data cannot be guaranteed, and the business controllability is poor. SUMMARY OF THE INVENTION In view of this, an embodiment of the present invention provides a method, a system, and a device for implementing a network service based on an open application programming interface, which are used to solve the problem of low security of service data and service when implementing network services based on the prior art. Poor control. The embodiment of the present invention is implemented by the following technical solution: According to an aspect of the embodiments of the present invention, a method for implementing a network service based on an open application programming interface is provided, including: receiving a pair sent by a third-party development server according to a service request of a user Opening an application request interface Open API call request; determining an Internet service provider ISP server corresponding to the Open API requested to be called in the call request, and sending the call request to the determined IS P server; Receiving a service page returned by the ISP server according to the call request, and sending the service page to the third-party development server, and the third-party development server processes the service page and sends the service page to The processing by the user is to encapsulate the service page in a page corresponding to the service request. According to another aspect of the embodiments of the present invention, an apparatus for implementing network services based on an open application programming interface is provided, including: 201209619, a first receiving unit, configured to receive, by a third-party development server, a pair sent according to a service request of a user An open request application interface Open API call request; a first ISP call unit, configured to determine an Internet service provider ISP server corresponding to the Open API requested to be called in the call request received by the first receiving unit, and The call request is sent to the ISP server determined by the isp determining unit; the first call result feedback unit is configured to receive a service page returned by the ISP server according to the call request sent by the first ISP call unit, And sending the service page to the third-party development server, and the third-party development server processes the service page and sends the service page to the user, where the processing is to encapsulate the service page in the The page corresponding to the business request. According to another aspect of the embodiments of the present invention, a system for implementing network services based on an open application programming interface is provided, including: a third-party development server, a service implementation server, and an ISP server; wherein, the third-party development server And sending a call request to the open application programming interface Open API to the service implementation server according to the service request of the user; and receiving the service page returned by the service implementation server, and encapsulating the service page in the service Sending the corresponding page to the user; the service implementation server is configured to determine, according to the call request sent by the third-party development server, the Internet corresponding to the Open -8 - 201209619 API requested in the call request The service provider ISP service request is sent to the determined service page returned by the ISP server ISP server, and the third-party server; the ISP server is configured to return the corresponding service according to the service utility request. The at least the network service provided by the service page is provided by the embodiment of the present invention. First, the ISP corresponding to the Open API requested to be called in the call request of the Open API sent by the third-party development service request is sent to the determined ISP; and the returned service page is received, and the service page sender is The third-party development server pairs the service page user, wherein the processing is to encapsulate the service page in the face. According to the technical solution, on the one hand, the service data is returned to the third-party development server, and the service data is in the form of structured data. Return to the first: Compared with 'improving the security of the data; on the other hand, with the ability to analyze the business logic, all the business third-party servers and the server between the ISs to control the business. Other features and advantages of the present invention will be apparent from the following and <RTIgt; The purpose of the present invention and other advantages are the server and the receiving of the service page is sent to the dispatch server sent by the server. A technical solution, in the server according to the user's request, determines the call request server, and the ISP according to the call request to the third-party development servo processing and then sent to the page service page corresponding to the service request will be in the prior art Directly control the three-party development server to the third-party server without the need to implement the instructions in the improved description, or through the implementation of the book can be written in the -9 - 201209619, the claims And the structures specifically indicated in the drawings are realized and obtained. [Embodiment] In order to provide an implementation scheme for improving service data security and improving service controllability, an embodiment of the present invention provides a method, system and device for implementing network service based on an open application programming interface, and the technical solution can be applied. The implementation process of the network service can be implemented as a method or as a device. The preferred embodiments of the present invention are described with reference to the accompanying drawings, which are intended to illustrate and illustrate the invention. And the features of the embodiments and the embodiments of the present invention may be combined with each other without conflict. According to an embodiment of the present invention, a method for implementing a network service based on an open application programming interface is first provided. As shown in FIG. 1 , the method mainly includes the following steps: Step 1 01: A service implementation server receives a third-party development server according to the following steps: A request to the Open API sent by the user's business request. Step 1 〇 2. The service implementation server determines the ISP corresponding to the Open API requested to be called in the received call request, and sends the call request to the determined ISP server. Step 103: The service implementation server receives the ISP server according to the call. The service page that is requested to be returned. Step 1 04: The service implementation server sends the service page to the third -10- 201209619 side development server, and the third party development server processes the service page and sends the service page to the user. In the step 104, the processing of the service page by the third-party development server is specifically: encapsulating the service page in a page corresponding to the service request, and implementing the network service through the foregoing process, and the method can be applied to multiple network environments. The service implementation server may be a server configured to control and manage services implemented in the network environment in a corresponding network environment; wherein the third-party development server may be an independent software provider. ISV server. In the embodiment of the present invention, if there are multiple Open APIs that are requested to be called in the call request, before sending the call request to the determined ISP server, that is, before performing the above step 102, the following steps are further performed: The calling relationship between Open APIs. The calling relationship between the plurality of Open APIs is used to indicate whether the multiple Open APIs have a calling order. According to an embodiment of the present invention, one calling request may simultaneously invoke multiple Open APIs, and the multiple Open APIs may include a calling sequence. The Open API can also include a separate Open API, which does not have a calling sequence with other Open APIs. Correspondingly, after determining the calling relationship between the multiple Open APIs, in step 102 of the flow shown in FIG. 1, the calling request is sent to the determined ISP server, as shown in FIG. 2, including the following steps: 11 - 201209619 Step 201: Determine whether there is a calling sequence between multiple Open APIs according to a calling relationship between multiple Open APIs. If yes, go to step 202, if no, go to step 203. Step 202: Send the call request to the ISP server corresponding to the Open API in the first order in the multiple Open APIs in which the call relationship exists, and then go to step 103 in FIG. Step 203: Send the call request to the corresponding ISP server of the multiple Open APIs, and then go to step 103 in FIG. In the embodiment of the present invention, when the 0Pen API requested to be called in the call request is multiple and the calling sequence exists between the multiple Open APIs, multiple calls according to the business logic are required, until the calling order is the last bit of the Open. The API is called. After the first call according to the calling sequence, before sending the service page to the third-party development server, that is, before performing step 1 〇4 in the flow shown in FIG. 1, the following steps may be further performed: The calling order between the Open APIs is encapsulated in the service page. Through the execution of the above steps, the calling order between the Open APIs is encapsulated in the service page returned to the user, and the user can trigger the calling process of the next Open API. As shown in FIG. 3, the process includes the following steps: Step 301: The service implementation server receives a call request of the second Open API after the first Open API that is currently triggered by the user according to the calling sequence encapsulated in the service page. -12- 201209619 Step 3〇2, send the call request to the ISP server corresponding to the second 0Pen API. Step 303: Receive an service page returned by the ISP server corresponding to the second Open API according to the call request. Step 304: Send the service page to the third-party development server. The service page is processed by the third-party development server and then sent to the user. According to the flow shown in FIG. 3, the service implementation server implements the calling process of the call request according to the call request of the next Open API triggered by the user. According to the preferred embodiment of the present invention, after the user triggers the call process of the 0Pen API, it can also support mutual calls between ISP servers corresponding to different Open APIs, for example, complex services involving multiple ISP server interactions. After calling the service provided by the ISP server corresponding to the first Open API, the service provided by the ISP server corresponding to the second Open API is further called, but the ISP server corresponding to the second Open API may only support the specific ISP. For the access of the server, the specific ISP server is generally the ISP server corresponding to the Open API that is called for the first time. In this case, the ISP corresponding to the second Open API needs to be called by the ISP server corresponding to the first Open API. The server, thereby realizing the acquisition of the service provided by the ISP server corresponding to the second Open API, specifically, the service implementation server implements the calling process of the call request according to the call request of the next Open API triggered by the user, and further As shown in FIG. 4, the method includes the following steps: Step 40: The service implementation server receives the user according to the service page -13-201209619 Calling a sequence-triggered call request to the second Open API after the first Open API that is currently called, step 402, determining, according to the calling relationship between the plurality of 〇pen APIs, whether the second Open API needs to pass the first Open API, If yes, go to step 403 to step 404, if no, go to steps 405 to 406. In this step 402, there is an inter-call relationship between the first 〇pen API and the second Open API, and the second Open API call needs to be completed by the first Open API. Step 403: Forward the call request to the ISP server corresponding to the second Open API by using an ISP server corresponding to the first Open API. Step 404: Receive the processed service page returned by the ISP server corresponding to the first Open API, and then go to step 407. In the step 404, the processing is specifically: the ISP server corresponding to the first Open API receives the service page returned by the ISP server corresponding to the second 〇pen API, and encapsulates the received service page in its own service page. return. Step 405: Send the call request to an ISP server corresponding to the second Open API. Step 406: Receive an ISP server corresponding to the second Open API according to the service page returned by the call request, and then jump to step 407. Step 407: Send the service page to a third-party development server, and the third-party development server processes the service page and sends the service page to the user. In the embodiment of the present invention, the service page returned by the ISP is encapsulated in the page corresponding to the service-14-201209619 request, and the specific information includes: embedding the service page into the page corresponding to the service request by using the embedded page Iframe. The page embedded in the Iframe format is an iframe element, which can be understood as a floating frame (FRAME) in the page. The frames collection provides access to the Iframe content. In a specific application, the frames collection can be used to read and write the elements contained in the ifranie.
Iframe也即inner Frame (嵌入頁面），是一種在已 有的Web頁面中嵌入另一個web頁面的技術，被嵌入的 Web頁面顯示在要嵌入頁面的web頁面中的指定的框架 位置’但對於用戶而言，不能感覺出當前展示的頁面是來 自於兩個不同的 Web頁面，因此，本發明實施例利用 Iframe的該特性，實現了 ISP服務的Web開放，保證了 安全性’同時也保證了用戶體驗。 本發明較佳實施例中，爲了增加業務實現的安全性以 及可控性，在確定調用請求中請求調用的對應的網際網路 服務提供商IS P之前，即在執行圖1所示流程的步驟1 〇 2 之前，還可以進一步包括如下步驟： 對發送業務請求的用戶進行鑒權，並在鑒權通過後執 行步驟1 0 2。 具體地，對發送業務請求的用戶進行鑒權，可以通過 多種方式’例如，向用戶返回登錄介面，該用戶若爲註冊 用戶’則通過登錄介面提示用戶提交註冊時的帳號以及密 碼資訊’若該用戶非註冊用戶，可通過登錄介面提示用戶 -15- 201209619 先進行註冊，在註冊資訊驗證通過後允許其登錄。 實際的業務實現過程中，一般涉及多次用戶與網路側 伺服器的交互，爲了保證用戶登錄的有效性，本發明實施 例在用戶成功登錄的基礎上，進一步驗證該用戶每次發送 業務請求時更新的與該業務請求對應的用戶登錄標識是否 有效，若有效，則對該用戶鑒權通過，否則拒絕該用戶的 業務請求。其中，用戶登錄標識在該用戶本次成功登錄後 創建。在具體業務實現過程中，可以通過如下方式實現用 戶登錄標識的創建及更新： 實際應用中，業務請求一般基於瀏覽器發送，在業務 實現伺服器驗證用戶本次登錄成功之後，向瀏覽器寫入本 次登錄過程中產生的用戶登錄標識 Cookie和寫入該 Cookie的時間資訊，用戶再次訪問時（如調用 Open API)，在驗證Cookie是否有效的時候，除了驗證用戶 ID的存在，還需要驗證再次訪問的時間和上述寫入的時 間之間的間隔是否在設定時間間隔內，即每次調用Open API時，業務實現伺服器都會驗證Cookie並在驗證通過 後刷新該Cookie。若用戶在長時間不調用Open API，則 在下次調用時需要重新登錄，以增加業務的安全性。 本發明實施例中，若確定的調用請求中請求調用的 Open API對應的ISP伺服器爲多個，將調用請求發送到 確定的ISP伺服器，具體包括： 將該調用請求發送到確定的多個ISP中的任意一個 ISP伺服器。 -16- 201209619 具體地’將該調用請求發送到確定的多個I s P中的任 意一個I S P伺服器’可以通過隨機路由演算法實現，即通 過隨機路由演算法將調用請求隨機發送到多個ISP伺服器 中的一台。同時對ISP伺服器做心跳檢測，根據ISP的狀 態對隨機列表進行動態更新。例如，若檢測到某I s P出現 異常，則從隨機列表中刪除該IS P，下次不會將調用請求 隨機發送到該伺服器；若檢測到該ISP恢復正常工作，則 從隨機列表中增加該I S P，下次可能將調用請求隨機發送 到該伺服器。 具體地，可以通過HTTP軟負載從多個ISP伺服器中 確定出用於提供業務的ISP。 HTTP軟負載基於一個中間件ConfigServer(即業務 實現伺服器）來實現，各ISP伺服器向ConfigServer註冊 HTTP 服務，ConfigServer 的用戶端根據 ConfigServer 中 的註冊位址，隨機連接ISP伺服器，並發送HTTP請求。 每個ISP服務通過一個ServerSide物件，將自己的地址資 訊發佈到 ConfigServer，每個用戶端（ClientSide)通過 —個ClientSide物件向 ConfigServer訂閱自己需要的服 務，ConfigServer會將所有可用服務的最新列表即時推送 給ClientSide，ClientSide通過某種路由演算法（也可以 隨機）選擇一個服務位址進行調用。具體地，發送到 ConfigServer的位址列表可以通過字串String表示。 本發明實施例中，ISP伺服器返回的服務頁面可以 較佳地包括如下兩種形式： -17- 201209619 方式一、ISP伺服器返回一服務頁面’ IS V將ISP返 回的服務頁面嵌入自身提供的服務頁面’最後返回給用戶 的結果頁面以ISP APP ( Application ’即開發者開發的 應用軟體）對應的功能變數名稱顯示’即將1SP APP的功 能變數名稱嵌入結果頁面返回給用戶，用戶能看到的功能 變數名稱爲ISPAPP的功能變數名稱。 方式二、ISP伺服器根據獲得的頁頭頁尾鏈結，渲染 好服務頁面返回給業務實現伺服器，最後返回給用戶的結 果頁面以業務實現伺服器對應的功能變數名稱顯示。其 中，ISP伺服器根據獲得的頁頭頁尾鏈結是ISV的APP通 過調用API時傳入的參數資訊，渲染服務頁面即將獲得的 參數資訊生成爲一個完整的頁面。 根據本發明實施例，能夠滿足不同的業務需要，例 如，有些業務要求顯示給用戶時必須以業務實現伺服器功 能變數名稱顯示，才能正常進行後續流程，比如退款操作 中需要用戶輸入密碼，爲了防止安全漏洞和後續糾紛，輸 入密碼框必須顯示在業務實現伺服器的功能變數名稱對應 的頁面下，用戶在確定功能變數名稱顯示無誤後，才執行 輸入密碼操作，以防止密碼被第三方竊取。 爲了更好地理解本發明實施例提供的技術方案，下面 以業務實現伺服器控制業務實現的具體實例對本發明的實 施例進行說明。 如圖5所示，爲該實施例中實現網路業務涉及的系統 交互示意圖，主要涉及的實體包括第三方開發伺服器 -18- 201209619 ISV、業務實現伺服器、多個ISP (爲表述方便，圖 出了 3個ISP)以及鑒權元件。其中： ISV發起的調用請求中可以包括頁面API調用（ 用存在調用關係的多個Open API)以及Rest API (即調用與其他 Open API不存在調用順序的 API )； 業務實現伺服器負責業務實現的安全和流量控制 圖5所示，業務實現伺服器作爲IS V和ISP之間的一 接器，負責將ISV調用 Open API的請求轉發到 ISP。一個API流程，包含多個與ISP交互的操作步 其中’既可以含有頁面交互的操作，也可以含有 REST API操作。同樣，一個ISP在處理流程頁面 時，還可以調用其他的ISP提供的服務，將其他ISP 的頁面以Iframee形式嵌入到自身提供的頁面中，再 給業務實現伺服器，由業務實現伺服器轉發給IS V ; 鑒權元件負責實現各種鑒權過程，例如，業務實 服器對於ISV的鑒權，ISP對應業務實現伺服器的 等。 如圖6所示，爲基於Open API實現業務的一個 實施例，其中，該業務流程需要調用三次Open API 且ISP1回應的第二步操作中，需要調用iSP2的服務 體包括如下步驟： 步驟601、用戶向ISV發起業務請求。 該步驟中’用戶發起的業務請求可以包括出價請 中畫 即調 調用 Open ，如 個連 相應 驟， 普通 API 提供 返回 現伺 鑒權 具體 ，並 ，具 求、 -19- 201209619 申請退款等請求。用戶需要登錄之後，才可以發起該業務 請求。 步驟602、ISV通過APP發起對Open API的調用請 求。 該步驟中，調用請求中包含調用API需要的參數及對 這些參數做的簽名資訊。 步驟603、業務實現伺服器收到請求後驗證用戶登錄 資訊以及Cookie，若驗證通過，繼續後續流程，否則攔 截用戶請求（該過程未在圖中標出）。 步驟604、業務實現伺服器驗證IS V訪問許可權，其 中包括通過驗證該ISV是否有調用該API的許可權及流 量控制，若驗證通過’繼續後續流程，否則拒絕調用請求 (該過程未在圖中標出）。 步驟6〇5、業務實現伺服器通過解析調用請求，確定 支援該Open API的ISP1，將調用請求轉發到ispi伺服 器。 步驟6 0 6、IS P 1伺服器收到調用請求後，驗證業務實 現伺服器簽名，如果簽名驗證成功，則繼續後續流程，否 則返回錯誤資訊（該過程未在圖中標出）。 步驟6 0 7、IS P 1伺服器返回服務頁面到業務實現伺服 器。 步驟608、業務實現伺服器封裝iSP1伺服器返回的 服務頁面，再返回給ISVAPP。 步驟609 ' IS V APP將返回的服務頁面封裝到自身提 -20- 201209619 供的應用頁面中，展示給用戶。 步驟6 1 0、用戶點擊返回的服務頁面，發起該流程的 第二步驟’該請求直接被發送到業務實現伺服器。 步驟6 1 1、業務實現伺服器收到該請求後，對用戶進 行鑒權’鑒權通過後繼續後續流程，否則返回錯誤資訊給 用戶（該過程未在圖中標出）。 步驟612、業務實現伺服器通過解析調用請求，將該 請求轉發給ISP1伺服器。 步驟6 1 3、I S P 1伺服器收到請求後，驗證業務實現伺 服器簽名，如果簽名驗證成功，則繼續後續流程，否則返 回錯誤資訊（該過程未在圖中標出）。 步驟614、ISP1伺服器通過解析該請求，確定需要調 用ISP2提供的服務，向ISP2伺服器發起調用ISP2的請 求。 步驟61 5、ISP2伺服器通過鑒權元件驗證用戶身份， 鑒權元件驗證用戶c ο 〇 k i e，驗證通過，則將驗證結果返回 IS P 2伺服器，並進行後續流程；否則跳轉到用戶登錄頁 面，要求用戶重新登錄（該過程未在圖中標出）。 步驟616、ISP2伺服器回應該服務請求，向iSP1伺 服器返回服務頁面。 步驟617、ISP1伺服器將ISP2伺服器返回的服務頁 面組裝到自身提供的頁面中返回給業務實現伺服器。 步驟6 1 8、業務實現伺服器將I S P 1伺服器返回的服 務頁面封裝轉發給ISV APP。 -21 - 201209619 步驟619、ISV APP將返回頁面組裝到自身提供的服 務頁面中展示給用戶。 步驟620、用戶點擊返回的服務頁面，發起該流程的 第三步驟，該請求直接被發送到業務實現伺服器。 步驟62 1、業務實現伺服器收到該請求後，對用戶進 行鑒權，鑒權通過後繼續後續流程，否則返回錯誤資訊給 用戶（該過程未在圖中標出）。 步驟622、業務實現伺服器通過解析調用請求，將該 請求轉發給I S P 1伺服器。 步驟623、ISP1伺服器收到請求後，驗證業務實現伺 服器簽名，如果簽名驗證成功，則繼續後續流程，否則返 回錯誤資訊（該過程未在圖中標出）。 步驟624、ISP1伺服器將自身提供的服務頁面返回給 ISV APP。 步驟62 5、ISV APP根據ISP1伺服器返回的結果資 訊’組裝結果頁面展示給客戶。 上述流程中，業務實現伺服器起連接中轉和控制監管 作用，外部I S V發起請求到業務實現伺服器，業務實現伺 服器收到請求後驗證該ISV是否有許可權訪問該頁面，如 果有許可權則發送請求到ISP，接受ISP簽名驗證，解析 ISP返回的資料，並返回給外部ISV。具體地，業務實現 伺服器和ISP之間可以採用HTTP方式進行調用，即ISP 提供HTTP服務’業務實現伺服器通過HTTP用戶端訪問 ISP頁面，即業務實現伺服器通過HTTP用戶端訪問isp -22- 201209619 的頁面，I S P將頁面內容直接輸出給業務實現伺服器。實 際應用中，業務實現伺服器接收到Open API調用請求之 後，會做以下判斷： 瀏覽器中的Cookie是否有效；An Iframe, also known as an inner frame, is a technique for embedding another web page in an existing web page. The embedded web page is displayed at a specified frame position in the web page to be embedded in the page 'but for the user In this case, the presently displayed page cannot be perceived as coming from two different web pages. Therefore, the embodiment of the present invention utilizes the feature of the Iframe to realize the Web opening of the ISP service, ensuring security while ensuring the user. Experience. In the preferred embodiment of the present invention, in order to increase the security and controllability of the service implementation, the steps of the process shown in FIG. 1 are performed before determining the corresponding Internet service provider IS P that is requested to be invoked in the call request. Before 〇2, the method further includes the following steps: authenticating the user who sends the service request, and performing step 1 0 2 after the authentication is passed. Specifically, the user who sends the service request is authenticated, and the login interface can be returned to the user in multiple ways, for example, if the user is a registered user, the user is prompted to submit the account and the password information through the login interface. Users who are not registered users can use the login interface to prompt the user -15- 201209619 to register first, and allow them to log in after the registration information is verified. The actual service implementation process generally involves multiple interactions between the user and the network side server. In order to ensure the validity of the user login, the embodiment of the present invention further verifies that the user sends a service request each time based on the successful login of the user. Whether the updated user login identifier corresponding to the service request is valid, and if valid, the user is authenticated, otherwise the service request of the user is rejected. The user login ID is created after the user successfully logs in this time. In the specific service implementation process, the user login ID can be created and updated in the following manner: In the actual application, the service request is generally sent based on the browser, and after the service implementation server verifies that the user successfully logs in, writes to the browser. The user login ID cookie generated during the login process and the time information written to the cookie. When the user accesses again (such as calling the Open API), when verifying that the cookie is valid, in addition to verifying the existence of the user ID, it is necessary to verify again. Whether the interval between the access time and the above written time is within the set time interval, that is, each time the Open API is called, the service implementation server verifies the cookie and refreshes the cookie after the verification is passed. If the user does not call the Open API for a long time, it needs to log in again on the next call to increase the security of the service. In the embodiment of the present invention, if the ISP server corresponding to the Open API that is requested to be invoked in the determined call request is multiple, sending the call request to the determined ISP server includes: sending the call request to the determined multiple Any ISP server in the ISP. -16- 201209619 Specifically, 'sending the call request to any one of the determined plurality of I s P's can be implemented by a random route algorithm, that is, the call request is randomly sent to multiple by a random route algorithm One of the ISP servers. At the same time, the heartbeat detection is performed on the ISP server, and the random list is dynamically updated according to the status of the ISP. For example, if an abnormality is detected in a certain s P, the IS P is deleted from the random list, and the call request is not randomly sent to the server next time; if the ISP is detected to resume normal operation, it is from the random list. Increasing the ISP, the next time the call request may be randomly sent to the server. Specifically, an ISP for providing a service can be determined from a plurality of ISP servers through an HTTP soft load. The HTTP soft load is implemented based on a middleware ConfigServer (that is, the service implementation server). Each ISP server registers the HTTP service with the ConfigServer. The client of the ConfigServer randomly connects to the ISP server according to the registered address in the ConfigServer, and sends an HTTP request. . Each ISP service publishes its own address information to ConfigServer through a ServerSide object. Each client (ClientSide) subscribes to the ConfigServer with its own service through a ClientSide object. ConfigServer will immediately push the latest list of all available services to ConfigServer. ClientSide, ClientSide is called by a routing algorithm (also randomly) to select a service address. Specifically, the address list sent to the ConfigServer can be represented by a string String. In the embodiment of the present invention, the service page returned by the ISP server may preferably include the following two forms: -17- 201209619 Mode 1: The ISP server returns a service page ' IS V embeds the service page returned by the ISP into its own provided The service page 'finally returned to the user's result page is displayed with the function variable name corresponding to the ISP APP (Application 'developer's application software). 'The function variable name of the 1SP APP is embedded in the result page and returned to the user. The user can see it. The function variable name is the function variable name of ISPAPP. In the second method, the ISP server returns the service page to the service implementation server according to the obtained page header and tail link, and finally returns the result page to the user to display the function variable name corresponding to the service implementation server. The ISP server generates a complete page based on the obtained page header and tail link, which is the parameter information input by the ISV APP when the API is called, and the parameter information to be obtained by the rendering service page is generated. According to the embodiment of the present invention, different service requirements can be met. For example, when some services are required to be displayed to the user, the server function variable name display must be performed in order to perform the subsequent process normally. For example, the user needs to input a password in the refund operation. To prevent security breaches and subsequent disputes, the input password box must be displayed on the page corresponding to the function variable name of the service implementation server. After the user determines that the function variable name is displayed correctly, the password operation is performed to prevent the password from being stolen by the third party. In order to better understand the technical solution provided by the embodiment of the present invention, the following describes an embodiment of the present invention by implementing a specific example of implementing a server control service. As shown in FIG. 5, it is a schematic diagram of system interaction involved in implementing network service in this embodiment, and the main entities involved include a third-party development server-18-201209619 ISV, a service implementation server, and multiple ISPs (for convenience of presentation, Figure 3 ISP) and authentication components. The request initiated by the ISV may include a page API call (using multiple Open APIs with a call relationship) and a Rest API (ie, an API that calls the call sequence with other Open APIs); the service implementation server is responsible for the service implementation. Security and Flow Control As shown in Figure 5, the service implementation server acts as a connector between the IS V and the ISP and is responsible for forwarding requests from the ISV to the Open API to the ISP. An API process that contains multiple steps to interact with an ISP where 'can contain either page interactions or REST API operations. Similarly, when an ISP processes a process page, it can also call other ISP-provided services to embed other ISP pages in the form of Iframee into the page provided by itself, and then implement the server for the service, and the service implementation server forwards it to the server. IS V ; The authentication component is responsible for implementing various authentication processes, for example, the authentication of the ISV by the service implementer, the implementation of the server by the ISP corresponding service, and the like. As shown in FIG. 6 , an embodiment of the service is implemented based on the Open API, where the service process needs to invoke the Open API three times and the second step of the ISP1 response, the service body that needs to invoke the iSP2 includes the following steps: Step 601: The user initiates a service request to the ISV. In this step, the user-initiated business request can include a bid, please call the Open, such as a corresponding step, the normal API provides a return to the current authentication specific, and, request, -19-201209619 request for a refund, etc. . The user can initiate the service request only after logging in. Step 602: The ISV initiates a call request to the Open API through the APP. In this step, the call request contains the parameters required to call the API and the signature information for these parameters. Step 603: After the service implementation server receives the request, the user login information and the cookie are verified. If the verification is passed, the subsequent process is continued, otherwise the user request is intercepted (the process is not marked in the figure). Step 604: The service implementation server verifies the IS V access permission, including verifying whether the ISV has permission to invoke the API and flow control, and if the verification passes the 'continue follow-up process, otherwise rejecting the call request (the process is not in the figure) Signed out). Step 6: 5. The service implementation server determines the ISP1 supporting the Open API by parsing the call request, and forwards the call request to the ispi server. Step 6 0 6. After the IS P 1 server receives the call request, the verification service implements the server signature. If the signature verification is successful, the subsequent process is continued, otherwise the error information is returned (the process is not marked in the figure). Step 6 0 7. The IS P 1 server returns the service page to the service implementation server. Step 608: The service implementation server encapsulates the service page returned by the iSP1 server, and returns to the ISVAPP. Step 609 ' IS V APP encapsulates the returned service page into the application page provided by itself to -20-201209619 and presents it to the user. Step 6 10 0. The user clicks on the returned service page to initiate the second step of the process. The request is sent directly to the service implementation server. Step 6 1 1. After the service implementation server receives the request, the user is authenticated. After the authentication is passed, the subsequent process is continued, otherwise the error information is returned to the user (the process is not marked in the figure). Step 612: The service implementation server forwards the request to the ISP1 server by parsing the call request. Step 6 1 3. After the I S P 1 server receives the request, the verification service implements the signature of the server. If the signature verification is successful, the subsequent process is continued, otherwise the error information is returned (the process is not marked in the figure). Step 614: The ISP1 server determines that the service provided by the ISP2 needs to be invoked by parsing the request, and initiates a request to invoke the ISP2 to the ISP2 server. Step 61 5. The ISP2 server verifies the identity of the user through the authentication component, and the authentication component verifies the user c ο 〇kie. If the verification passes, the verification result is returned to the IS P 2 server, and the subsequent process is performed; otherwise, the user login page is redirected. Require users to log in again (this process is not marked in the figure). In step 616, the ISP2 server responds to the service request and returns a service page to the iSP1 server. Step 617: The ISP1 server assembles the service page returned by the ISP2 server to the page provided by itself and returns it to the service implementation server. Step 6 1 8. The service implementation server forwards the service page package returned by the I SP server to the ISV APP. -21 - 201209619 Step 619, the ISV APP will assemble the return page to the user's service page and display it to the user. Step 620: The user clicks on the returned service page to initiate a third step of the process, and the request is directly sent to the service implementation server. Step 62: After the service implementation server receives the request, the user is authenticated, and the subsequent process is continued after the authentication is passed, otherwise the error information is returned to the user (the process is not marked in the figure). Step 622: The service implementation server forwards the request to the SIP server by parsing the call request. Step 623: After receiving the request, the ISP1 server verifies that the service implements the signature of the server. If the signature verification is successful, the subsequent process is continued, otherwise the error information is returned (the process is not marked in the figure). Step 624: The ISP1 server returns the service page provided by itself to the ISV APP. Step 62 5. The ISV APP displays the results of the assembly result page returned to the customer according to the ISP1 server. In the above process, the service implementation server acts as a connection relay and control supervision, and the external ISV initiates a request to the service implementation server, and the service implementation server verifies whether the ISV has permission to access the page after receiving the request, if there is permission Then send the request to the ISP, accept the ISP signature verification, parse the data returned by the ISP, and return it to the external ISV. Specifically, the service implementation server and the ISP can be invoked by using an HTTP method, that is, the ISP provides an HTTP service. The service implementation server accesses the ISP page through the HTTP client, that is, the service implementation server accesses the isp -22 through the HTTP client. On the 201209619 page, the ISP outputs the page content directly to the service implementation server. In the actual application, after the service implementation server receives the Open API call request, it will make the following judgment: Whether the cookie in the browser is valid;
Sign參數是否合法；其中的Sign參數用於驗證ISV 用戶傳入的資料，該參數在ISV調用API前根據ISV與 業務實現伺服器約定演算法生成，並在調用API時傳入； Appkey參數是否合法，且是否具備當前頁面API的 訪問許可權；訪問每個API的應用都有一個唯一標識及密 鑰，稱之爲 Appkey 參’數（包括 Appkey 和 APP Secret )，分別用來對每個應用做身份認證及安全控制， 該參數在ISV調用API時傳入；Whether the Sign parameter is legal; the Sign parameter is used to verify the data sent by the ISV user. This parameter is generated according to the ISV and the service implementation server contract algorithm before the ISV calls the API, and is passed in when the API is called. Is the Appkey parameter legal? And whether it has the access permission of the current page API; the application that accesses each API has a unique identifier and key, called Appkey parameter number (including Appkey and APP Secret), which are used to make each application separately. Identity authentication and security control, this parameter is passed in when the ISV calls the API;
Session參數和Cookie中的用戶是否對應；ISV開發 的應用在獲取業務實現伺服器提供的資訊時，如果該資訊 爲用戶的私有資訊，需要用戶登錄後才能獲取，該 Session參數（即Session key)是用戶登錄後獲取，用來 表明該資料經過用戶授權可以獲取，該資訊在用戶登錄時 產生，調用API時傳入；The session parameter corresponds to the user in the cookie. When the application developed by the ISV obtains the information provided by the service implementation server, if the information is the user's private information, the user needs to log in to obtain the session parameter (the session key). The user obtains after logging in to indicate that the data can be obtained through user authorization. The information is generated when the user logs in, and is transmitted when the API is called.
Timestamp參數和當前時間間隔是否在 30分鐘以 內；其中的Timestamp參數用於控制ISV應用訪問API 的次數，由業務實現伺服器生成，並寫入用戶瀏覽器 Cookie，用戶通過頁面訪問API時，讀取cookie獲取；Whether the Timestamp parameter and the current time interval are within 30 minutes; the Timestamp parameter is used to control the number of times the ISV application accesses the API, generated by the service implementation server, and written to the user's browser cookie. When the user accesses the API through the page, the user reads Cookie acquisition;
Session參數對應的用戶是否具備訪問對應appkey的 許可權； -23- 201209619 不 權 鑒 戶 用 對 定 確 則 足 滿 不 條 1 何 任 則 規 述 上 ml/ 如 通過。 進一步地，上述流程中，鑒權元件提供了統一的登錄 驗證功能，實際應用中，該鑒權元件可以以獨立伺服器的 形式存在，即採用與業務實現伺服器的功能變數名稱、 ISP的功能變數名稱不同的功能變數名稱。在業務實現伺 服器的域中寫入Cookie，在其他IS P鑒權時只要驗證業 務實現伺服器的域中的Cookie是否存在，爲了使其他域 能訪問該業務實現伺服器域中的Cookie，訪問時可以使 用 P3P header 實現。 採用鑒權元件實現鑒權的具體處埋流程如圖7所示， 包括如下步驟： 步驟701、用戶向ISV發送登錄請求。 步驟702、ISV通過APP將該登錄請求轉發到業務實 現伺服器，同時將自身鑒權參數傳給業務實現伺服器。 步驟703、業務實現伺服器收到請求後，發送登錄請 求到鑒權元件。 步驟704、鑒權元件收到業務實現伺服器的登錄請求 後’跳轉到用戶登錄頁面’用戶輸入用戶名和密碼，驗證 成功’執行後續步驟，否則跳回登錄頁面（該過程未在圖 中標出）。 步驟7 05、鑒權元件向業務實現伺服器發起寫c〇okie 請求。 步驟706、業務實現伺服器收到請求後，根據請求參 -24- 201209619 數做安全驗證，驗證通過後，寫入cookie。 步驟707、業務實現伺服器將寫入成功回應返回 元件。 上述基於Open API實現網路業務的方法還可以 爲一種系統，如圖8所示，爲本發明實施例提供的基 放應用編程介面實現網路業務的系統對應的網路拓撲 其中包括： 第三方開發伺服器801、業務實現伺服器802 ISP伺服器8 0 3 (實際應用中，ISP伺服器爲多個， 爲了簡化起見，僅示出了 2個）。 業務實現伺服器802用戶對網路業務進行整體調 及控制，具體地，各伺服器分別完成如下功能= 第三方開發伺服器801，用於根據用戶的業務請 業務實現伺服器8 02發送對開放應用編程介面Open 的調用請求；以及，接收業務實現伺服器802返回的 頁面，並將該服務頁面封裝在業務請求對應的頁面中 給用戶； 業務實現伺服器8 02，用於根據第三方開發伺 80 1發送的調用請求，確定該調用請求中請求調用的 API對應的網際網路服務提供商ISP伺服器8 03，並 調用請求發送到確定的ISP伺服器803 ;以及，接收 伺服器返回的服務頁面，並將該服務頁面發送給第三 服器8 0 1 ; ISP伺服器8 03，用於根據業務實現伺服器802 鑒權 實現 於開 圖， 以及 圖 8 度以 求向 API 服務 發送 服器 Open 將該 ISP 方伺 發送 -25- 201209619 的調用請求返回相應的服務頁面給業務實現伺服器8 02。 上述基於Open API實現網路業務的方法還可以實現 爲一種裝置，如圖9所示，與上述方法流程對應，本發明 實施例還提供了 一種基於開放應用編程介面實現網路業務 的裝置，該裝置包括： 第一接收單元901、第一ISP調用單元902以及第一 調用結果反饋單元903 ; 其中： 第一接收單元90 1，用於接收第三方開發伺服器根據 用戶的業務請求發送的對開放應用編程介面Open API的 調用請求； 第一 ISP調用單元902，用於確定第一接收單元901 接收的調用請求中請求調用的Open API對應的網際網路 服務提供商ISP伺服器，並將所述調用請求發送到所述 ISP確定單元確定的所述ISP伺服器； 第一調用結果反饋單元903，用於接收ISP伺服器根 據第一 ISP調用單元902發送的調用請求返回的服務頁 面，並將所述服務頁面發送到第三方開發伺服器，由第三 方開發伺服器對所述服務頁面進行處理後發送給所述用 戶，所述處理爲將所述服務頁面封裝在所述業務請求對應 的頁面中。 如圖1 〇所示，本發明較佳實施例中，圖9所示的第 —ISP調用單元902還可以具體包括：調用關係確定模組 902A、第一調用執行模組902B以及第二調用執行模組 -26- 201209619 902C ;其中： 調用關係確定模組902A，用於在第一接收單元901 接收的調用請求中請求調用的Open API爲多個，確定該 多個Open API之間的調用關係； 第一調用執行模組902B，用於在根據調用關係確定 模組902A確定的調用關係確定所述多個〇pen API之間 存在調用順序時，將所述調用請求發送到所述多個Open API中調用順序處於第一位的〇pen API對應的ISP伺服 器； 第二調用執行模組902C，用於在根據調用關係確定 模組9 0 2 A確定的調用關係確定所述多個〇 p e n A P I之間 不存在調用順序時，將所述調用請求發送到所述多個 Open API分別對應的ISP伺服器。 如圖1 1所示’本發明較佳實施例中，圖9所示的裝 置，還可以進一步包括： 調用關係封裝單元9〇4，用於在根據調用關係確定所 述多個Open API之間存在調用順序時，將所述多個〇pen API之間的調用順序封裝在所述服務頁面中，並將封裝處 理後的服務頁面提供給所述第一調用結果反饋單元9〇3。 如圖12所示’本發明較佳實施例中，圖9所示的裝 置還可以進一步包括： 第二接收單元90 5、第二ISP調用單元906以及第二 調用結果反饋單元907; 其中： -27- 201209619 第二接收單元905，用於接收所述用戶根據第一調用 結果反饋單元903返回的服務頁面中封裝的所述調用順序 觸發的對當前調用的第一 Open API之後的第二Open API 的調用請求； 第二ISP調用單元906，用於將第二接收單元9〇5調 用請求發送到與所述第二Open API對應的ISP伺服器； 第二調用結果反饋單元907，用於接收所述第二Open API對應的ISP伺服器根據第二ISP調用單元906發送的 調用請求返回的服務頁面，並將所述服務頁面發送到第三 方開發伺服器，由第三方開發伺服器對所述服務頁面進行 處理後發送給所述用戶。 如圖13所示，本發明較佳實施例中，圖12所示裝置 包括的第二ISP調用單元906，具體包括： 調用關係解析模組906 A，用於在將第二接收單元 905接收的調用請求發送到與所述第二Open API對應的 ISP伺服器之前，根據所述多個Open API之間的調用關 係確定所述第二Open API是否需要通過所述第一 Open API調用所述第二Open API ; 調用請求發送模組90 6B，用於在調用關係解析模組 9 06A的確定結果爲是時，通過所述第一 Open API對應的 ISP伺服器將所述調用請求轉發至所述第二Open API對 應的ISP伺服器； 相應地，該實施例中，圖12所示裝置包括的第二調 用結果反饋單元907，具體包括： -28- 201209619 接收模組907A，用於接收所述第一 Open API對應的 I s P伺服器返回的處理後的服務頁面，其中，所述服務頁 面時所述第一 Open API對應的ISP伺服器接收所述第二 Open API對應的ISP伺服器返回的服務頁面，並將接收 的該服務頁面封裝在自身提供的服務頁面中返回的； 反饋模組907B，用於將接收模組907A接收的服務頁 面發送到所述第三方開發伺服器，由所述第三方開發伺服 器對所述服務頁面進行處理後發送給所述用戶。 如圖1 4所示，本發明較佳實施例中，圖9所示的裝 置還可以進一步包括： 鑒權單元908，用於對發送所述業務請求的用戶鑒 權，並在確定對所述用戶鑒權通過後，指示第一 ISP調用 單元902確定所述調用請求中請求調用的Open API對應 的網際網路服務提供商ISP伺服器。 如圖1 5所示，本發明較佳實施例中，圖1 4所示裝置 包括的鑒權單元908可以進一步包括： 鑒權模組90 8 A，用於在確定所述用戶滿足設定條件 時確定對所述用戶鑒權通過：其中，所述設定條件包括： 在所述用戶成功登錄時，創建用戶登錄標識；並 確定在所述用戶每次發送業務請求時更新的所述用戶 的用戶登錄標識爲有效； 指示模組908B，用於在鑒權模組908A鑒權通過後， 指示第一 ISP調用單元902確定所述調用請求中請求調用 的Open API對應的網際網路服務提供商ISP伺服器。 -29- 201209619 如圖16所示，本發明較佳實施例中，圖9所示裝置 包括的第一 ISP調用單元902，還可以進一步包括： ISP伺服器確定模組902D，用於確定所述調用請求中 請求調用的Open API對應的ISP個數； ISP伺服器選擇模組902E，用於當所述ISP伺服器確 定模組902D確定的ISP爲多個時，採用隨機路由演算法 在確定的所述多個ISP中定位一個ISP伺服器，並將所述 調用請求發送到定位到的ISP伺服器。 本發明的實施例所提供的基於開放應用編程介面實現 網路業務的裝置所實現功能的具體方式或/和手段在上述 方式實施例中的相應處理步驟中已詳細說明，在此不再贅 述。 本發明實施例提供的基於開放應用編程介面實現網路 業務的裝置，可以作爲單獨的裝置存在。在實際應用中， 考慮到網路結構的簡化，可以將該裝置實現的功能集成在 業務實現伺服器中，例如，在業務實現伺服器中增加該裝 置爲實現上述功能對應的單元。並且本發明的實施例所提 供的基於開放應用編程介面實現網路業務的裝置可通過電 腦程式實現。本領域技術人員應該能夠理解，上述的模組 劃分方式僅是衆多模組劃分方式中的一種，如果劃分爲其 他模組或不劃分模組，只要該裝置具有上述功能，都應該 在本發明的保護範圍之內。 本發明是參照根據本發明實施例的方法、設備（系 統）、和電腦程式產品的流程圖和/或方框圖來描述的。 -30- 201209619 應理解可由電腦程式指令實現流程圖和/或方框圖中的每 —流程和/或方框、以及流程圖和/或方框圖中的流程和 /或方框的結合。可提供這些電腦程式指令到通用電腦、 專用電腦、嵌入式處理機或其他可編程資料處理設備的處 理器以產生一個機器’使得通過電腦或其他可編程資料處 理設備的處理器執行的指令產生用於實現在流程圖一個流 程或多個流程和/或方框圖一個方框或多個方框中指定的 功能的裝置。 這些電腦程式指令也可存儲在能引導電腦或其他可編 程資料處理設備以特定方式工作的電腦可讀記憶體中，使 得存儲在該電腦可讀記憶體中的指令產生包括指令裝置的 製造品，該指令裝置實現在流程圖一個流程或多個流程和 /或方框圖一個方框或多個方框中指定的功能。 這些電腦程式指令也可裝載到電腦或其他可編程資料 處理設備上，使得在電腦或其他可編程設備上執行一系列 操作步驟以產生電腦實現的處理，從而在電腦或其他可編 程設備上執行的指令提供用於實現在流程圖一個流程或多 個流程和/或方框圖一個方框或多個方框中指定的功能的 步驟。 通過本發明實施例提供的上述至少一個技術方案’在 貫現網路業務時，首先接收第三方開發伺服器根據用戶的 業務請求發送的對Open API的調用請求’確定該調用請 求中請求調用的〇 p e n A PI對應的I S P，並將該調用請求 發送到確定的ISP;進而接收該ISP根據調用請求返回的 -31 - 201209619 服務頁面，並將該服務頁面發送到第三方開發伺服器，由 該第三方開發伺服器對服務頁面進行處理後發送給用戶， 其中的處理爲將服務頁面封裝在業務請求對應的頁面中， 根據該技術方案，一方面，通過服務頁面的形式將服務資 料返回給第三方開發伺服器，與現有技術中直接將服務資 料以結構化資料形式返回給第三方開發伺服器相比，提高 了資料的安全性；另一方面，第三方伺服器無需具備對業 務邏輯分析的功能，所有業務的控制都通過介於第三方伺 服器以及各ISP之間的伺服器實現，從而提高了對業務的 可控性。 顯然，本領域的技術人員可以對本發明進行各種改動 和變型而不脫離本發明的精神和範圍。這樣，倘若本發明 的這些修改和變型屬於本發明申請專利範圍及其等同技術 的範圍之內，則本發明也意圖包含這些改動和變型在內。 【圖式簡單說明】 附圖用來提供對本發明的進一步理解，並且構成說明 書的一部分，與本發明實施例一起用於解釋本發明，並不 構成對本發明的限制。在附圖中： 圖1爲本發明實施例提供的基於open API實現網路 業務的方法流程圖一； 圖2爲本發明實施例提供的將調用請求發送到I S P伺 服器的流程圖： 圖3爲本發明實施例提供的觸發的下一Open API的 -32- 201209619 調用流程圖一； 圖4爲本發明實施例提供的觸發的下一Open API的 調用流程圖二； 圖5爲本發明實施例提供的實現網路業務涉及的系統 交互示意圖； 圖6爲本發明實施例提供的基於〇pen API實現網路 業務的流程圖二； 圖7爲本發明實施例提供的採用鑒權元件實現鑒權的 流程圖； 圖8爲本發明實施例提供的基於Open API實現網路 業務的系統示意圖； 圖9爲本發明實施例提供的基於Open API實現網路 業務的裝置示意圖一； 圖1 0爲本發明實施例提供的第一IS P調用單元結構 示意圖一； 圖1 1爲本發明實施例提供的基於Open API實現網路 業務的裝置示意圖二； 圖1 2爲本發明實施例提供的基於Open API實現網路 業務的裝置示意圖三； 圖13爲本發明實施例提供的第二ISP調用單元以及 第二調用結果反饋單元的結構示意圖； 圖14爲本發明實施例提供的基於Open API實現網路 業務的裝置示意圖四： 圖1 5爲本發明實施例提供的鑒權單元的結構示意 -33- 201209619 圖； 圖1 6爲本發明實施例提供的第一 ISP調用單元結構 示意圖二。 【主要元件符號說明】 801 :第三方開發伺服器 8 02 :業務實現伺服器 803 : ISP伺服器 901 :第一接收單元 902 :第一ISP調用單元 902A :調用關係確定模組 902B :第一調用執行模組 902C :第二調用執行模組 902D : ISP伺服器確定模組 902E : ISP伺服器選擇模組 903 :第一調用結果反饋單元 904 :調用關係封裝單元 905 :第二接收單元 906 :第二ISP調用單元 906A :調用關係解析模組 906B :調用請求發送模組 907 :第二調用結果反饋單元 907A :接收模組 907B :反饋模組 -34- 201209619 908 :鑒權單元 908 A :鑒權模組 9 0 8 B :指示模組Whether the user corresponding to the Session parameter has the permission to access the corresponding appkey; -23- 201209619 The user is not authorized to use the correctness and is not sufficient. 1 Where is the rule ml/ if passed. Further, in the above process, the authentication component provides a unified login verification function. In an actual application, the authentication component may exist in the form of a separate server, that is, the function variable name and the ISP function of the server are implemented by using the service. A function variable name with a different variable name. Write a cookie in the domain of the service implementation server. In other IS P authentication, just verify that the cookie in the domain of the service implementation server exists, in order to enable other domains to access the service to implement cookies in the server domain, access It can be implemented using the P3P header. As shown in FIG. 7 , the specific embedding process for implementing authentication by using the authentication component includes the following steps: Step 701: The user sends a login request to the ISV. Step 702: The ISV forwards the login request to the service implementation server through the APP, and transmits the self-authentication parameter to the service implementation server. Step 703: After receiving the request, the service implementation server sends a login request to the authentication component. Step 704: After the authentication component receives the login request of the service implementation server, the user jumps to the user login page and enters the user name and password. The verification succeeds. 'The subsequent steps are performed, otherwise the login page is skipped (the process is not marked in the figure). ). Step 7 05: The authentication component initiates a write c〇okie request to the service implementation server. Step 706: After receiving the request, the service implementation server performs security verification according to the number of requests -24-201209619, and writes the cookie after the verification is passed. Step 707: The service implementation server returns a successful response to the return component. The method for implementing the network service based on the Open API may also be a system. As shown in FIG. 8, the network topology corresponding to the system for implementing the network service application programming interface provided by the embodiment of the present invention includes: Development server 801, service implementation server 802 ISP server 803 (In practical applications, there are a plurality of ISP servers, and only two are shown for the sake of simplicity). The service implementation server 802 user performs overall reconciliation control on the network service. Specifically, each server performs the following functions respectively: The third-party development server 801 is configured to open the server to enable the service to be opened according to the service of the user. The calling request of the application programming interface Open; and receiving the page returned by the service implementation server 802, and encapsulating the service page in the page corresponding to the service request to the user; the service implementation server 802 for developing according to the third party 80 1 sends a call request, determines an Internet service provider ISP server 803 corresponding to the API requested to be called in the call request, and invokes the request to be sent to the determined ISP server 803; and receives the service returned by the server The page is sent to the third server 802; the ISP server 803 is used to implement the server 802 authentication according to the service implementation, and the figure 8 is used to send the server to the API service. Open sends the ISP's request to send the -25-201209619 call back to the corresponding service page to the service implementation server 802. The method for implementing the network service based on the Open API may also be implemented as a device. As shown in FIG. 9 , the embodiment of the present invention further provides a device for implementing network services based on an open application programming interface. The device includes: a first receiving unit 901, a first ISP invoking unit 902, and a first invoking result feedback unit 903; wherein: the first receiving unit 901 is configured to receive a pair of third-party development servers that are sent according to a service request of the user. The application request interface Open API call request; the first ISP invoking unit 902 is configured to determine an Internet service provider ISP server corresponding to the Open API requested to be called in the call request received by the first receiving unit 901, and The call request is sent to the ISP server determined by the ISP determining unit; the first call result feedback unit 903 is configured to receive a service page returned by the ISP server according to the call request sent by the first ISP calling unit 902, and The service page is sent to a third-party development server, and the third-party development server performs the service page. After the processing is sent to the user, the processing for the page is encapsulated in the service page corresponding to the service request. As shown in FIG. 1 , in the preferred embodiment of the present invention, the first ISP invoking unit 902 shown in FIG. 9 may further include: a call relationship determining module 902A, a first calling execution module 902B, and a second call execution. The module -26-201209619 902C; wherein: the call relationship determining module 902A is configured to request a plurality of Open APIs to be called in the call request received by the first receiving unit 901, and determine a calling relationship between the multiple Open APIs. The first call execution module 902B is configured to send the call request to the multiple Opens when determining that there is an invocation sequence between the plurality of 〇pen APIs according to the call relationship determined by the call relationship determination module 902A The API calls the ISP server corresponding to the 〇pen API in the first order; the second call execution module 902C is configured to determine the plurality of 〇pens according to the calling relationship determined by the calling relationship determining module 902 A When there is no calling sequence between the APIs, the calling request is sent to the ISP server corresponding to the plurality of Open APIs respectively. In the preferred embodiment of the present invention, the apparatus shown in FIG. 9 may further include: a call relationship encapsulating unit 〇4 for determining between the plurality of Open APIs according to the calling relationship. When there is a calling sequence, the calling sequence between the plurality of 〇pen APIs is encapsulated in the service page, and the encapsulated processed service page is provided to the first call result feedback unit 〇3. As shown in FIG. 12, in the preferred embodiment of the present invention, the apparatus shown in FIG. 9 may further include: a second receiving unit 90 5, a second ISP calling unit 906, and a second calling result feedback unit 907; wherein: The second receiving unit 905 is configured to receive, by the user, the second Open API after the first Open API that is currently invoked according to the calling sequence encapsulated in the service page returned by the first call result feedback unit 903. The second ISP invoking unit 906 is configured to send the second receiving unit 9〇5 calling request to the ISP server corresponding to the second Open API; the second calling result feedback unit 907 is configured to receive the The ISP server corresponding to the second Open API returns the service page according to the call request sent by the second ISP calling unit 906, and sends the service page to the third-party development server, and the third-party development server serves the service. The page is processed and sent to the user. As shown in FIG. 13 , in the preferred embodiment of the present invention, the second ISP invoking unit 906 is included in the apparatus shown in FIG. 12, and specifically includes: a call relationship parsing module 906 A for receiving the second receiving unit 905. Determining, according to the calling relationship between the plurality of Open APIs, whether the second Open API needs to invoke the first Open API by using the ISP server corresponding to the second Open API a second Open API; a call request sending module 90 6B, configured to forward the call request to the ISP server corresponding to the first Open API when the determination result of the call relationship parsing module 906A is YES The ISP server corresponding to the second Open API; correspondingly, in this embodiment, the second call result feedback unit 907 included in the apparatus shown in FIG. 12 specifically includes: -28- 201209619 Receive module 907A, configured to receive the The processed service page returned by the IP server corresponding to the first Open API, wherein the ISP server corresponding to the first Open API receives the ISP server return corresponding to the second Open API when the service page is of The service page is encapsulated in the service page provided by itself, and the feedback module 907B is configured to send the service page received by the receiving module 907A to the third-party development server, The third-party development server processes the service page and sends it to the user. As shown in FIG. 14 , in the preferred embodiment of the present invention, the apparatus shown in FIG. 9 may further include: an authentication unit 908, configured to authenticate a user that sends the service request, and determines After the user authentication is passed, the first ISP invoking unit 902 is instructed to determine an Internet service provider ISP server corresponding to the Open API requested to be invoked in the calling request. As shown in FIG. 15 , in the preferred embodiment of the present invention, the authentication unit 908 included in the apparatus shown in FIG. 14 may further include: an authentication module 908 A for determining that the user meets the set condition. Determining the authentication of the user: wherein the setting condition comprises: creating a user login identifier when the user successfully logs in; and determining a user login of the user updated each time the user sends a service request The identifier is valid; the indication module 908B is configured to, after the authentication module 908A authenticates, pass the first ISP invoking unit 902 to determine the Internet service provider ISP servo corresponding to the Open API requested in the call request. Device. -29-201209619 As shown in FIG. 16, in the preferred embodiment of the present invention, the first ISP invoking unit 902 included in the apparatus shown in FIG. 9 may further include: an ISP server determining module 902D, configured to determine the The number of ISPs corresponding to the Open API requested in the call is requested; the ISP server selection module 902E is configured to determine the ISP when the ISP determines that the ISP determined by the module 902D is multiple. An ISP server is located in the plurality of ISPs, and the call request is sent to the located ISP server. The specific manners and/or means for implementing the functions of the device for implementing the network service based on the open application programming interface provided by the embodiment of the present invention have been described in detail in the corresponding processing steps in the foregoing embodiments, and are not described herein. The device for implementing network service based on the open application programming interface provided by the embodiment of the present invention may exist as a separate device. In practical applications, considering the simplification of the network structure, the functions implemented by the device can be integrated into the service implementation server. For example, the device is added to the service implementation server to implement the corresponding function. And the device for implementing network services based on the open application programming interface provided by the embodiment of the present invention can be implemented by a computer program. Those skilled in the art should be able to understand that the above-mentioned module division manner is only one of a plurality of module division manners. If the module is divided into other modules or not divided into modules, as long as the device has the above functions, it should be in the present invention. Within the scope of protection. The present invention has been described with reference to flowchart illustrations and/or block diagrams of a method, apparatus (system), and computer program product according to embodiments of the invention. -30-201209619 It should be understood that each of the flow and/or block diagrams, and the combinations of the flow and/or blocks in the flowcharts and/or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, a special purpose computer, an embedded processor or other programmable data processing device to generate a machine that enables the generation of instructions by a processor of a computer or other programmable data processing device. Means for implementing the functions specified in one or more of the flow or in a block or blocks of the flow chart. The computer program instructions can also be stored in a computer readable memory that can boot a computer or other programmable data processing device to operate in a particular manner, such that instructions stored in the computer readable memory produce an article of manufacture including the instruction device. The instruction means implements the functions specified in one or more blocks of the flow or in a flow or block diagram of the flowchart. These computer program instructions can also be loaded onto a computer or other programmable data processing device to perform a series of operational steps on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device. The instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram. According to the above at least one technical solution provided by the embodiment of the present invention, when the network service is implemented, the third-party development server first receives a call request for the Open API sent by the third-party development server according to the service request of the user, and determines the request to be invoked in the call request. 〇pen A PI corresponding ISP, and send the call request to the determined ISP; and then receive the -31 - 201209619 service page returned by the ISP according to the call request, and send the service page to the third-party development server, by The third-party development server processes the service page and sends it to the user, where the processing is to encapsulate the service page in the page corresponding to the service request. According to the technical solution, on the one hand, the service data is returned to the service page. The three-party development server improves the security of the data compared with the prior art directly returning the service data to the third-party development server in the form of structured data; on the other hand, the third-party server does not need to have analysis of the business logic. Function, all business controls are passed between third-party servers and ISPs Between server implementations, thereby improving the controllability of the business. It is apparent that those skilled in the art can make various modifications and variations to the invention without departing from the spirit and scope of the invention. Thus, it is intended that the present invention cover the modifications and variations of the invention, BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings are intended to provide a further understanding of the invention In the drawings: FIG. 1 is a flowchart 1 of a method for implementing a network service based on an open API according to an embodiment of the present invention; FIG. 2 is a flowchart of sending a call request to an ISP server according to an embodiment of the present invention: FIG. 4 is a flow chart 2 of the next Open API triggered by the triggering of the next Open API provided by the embodiment of the present invention; FIG. 4 is a flowchart of the next Open API call triggered by the embodiment of the present invention; FIG. 6 is a flowchart 2 of implementing network service based on 〇pen API according to an embodiment of the present invention; FIG. 7 is a schematic diagram of implementing authentication by using an authentication component according to an embodiment of the present invention; FIG. 8 is a schematic diagram of a system for implementing network services based on the Open API according to an embodiment of the present invention; FIG. 9 is a schematic diagram of a device for implementing network services based on the Open API according to an embodiment of the present invention; FIG. 1 is a schematic diagram 2 of a device for implementing a network service based on an Open API according to an embodiment of the present invention; FIG. FIG. 13 is a schematic structural diagram of a second ISP invoking unit and a second invoking result feedback unit according to an embodiment of the present invention; FIG. 14 is a schematic diagram of a second embodiment of the present invention; FIG. 15 is a schematic diagram of an authentication unit according to an embodiment of the present invention. FIG. 15 is a schematic diagram of an authentication unit provided by an embodiment of the present invention. FIG. 16 is a first ISP calling unit according to an embodiment of the present invention. Structure II. [Main component symbol description] 801: Third-party development server 8 02: service implementation server 803: ISP server 901: first receiving unit 902: first ISP calling unit 902A: calling relationship determining module 902B: first call Execution module 902C: second call execution module 902D: ISP server determination module 902E: ISP server selection module 903: first call result feedback unit 904: call relationship encapsulation unit 905: second reception unit 906: The second ISP calling unit 906A: the call relationship parsing module 906B: the call request sending module 907: the second calling result feedback unit 907A: the receiving module 907B: the feedback module -34 - 201209619 908: the authentication unit 908 A: authentication Module 9 0 8 B : indicator module