ONLINE BUSINESS METHOD, SYSTEM AND APPARATUS BASED ON OPEN APPLICATION PROGRAMMING INTERFACE

• US 20150341451A1
• Filed: 08/05/2015
• Published: 11/26/2015
• Est. Priority Date: 06/10/2010
• Status: Active Grant

• Current Assignee: Alibaba Group Holding Ltd.
• Original Assignee: Alibaba Group Holding Ltd.
• Inventors: Lin, Tao, Li, Junxu
• Granted Patent: US 9,699,257 B2
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: G06F 21/31 User authentication
• CPC Class Codes: G06F 21/33 using certificates
• CPC Class Codes: G06F 9/54 Interprogram communication
• CPC Class Codes: G06F 9/547 Remote procedure calls [RPC]; Web services
• CPC Class Codes: H04L 67/52 specially adapted for the location of the user terminal
• CPC Class Codes: H04L 67/53 using third party service providers

Abstract

The present disclosure introduces a method, a system and an apparatus of implementing online transaction according to Open API. In one aspect, a method includes: receiving a first invocation request to invoke an Open API from a third party development server according to a user'"'"'s transaction request; determining an ISP server corresponding to the Open API as requested to be invoked in the invocation request; sending the first invocation request to the determined ISP server; receiving a service page returned by the ISP server according to the first invocation request; and sending the service page to the third party development server for processing the service page and sending the processed service page to the user, the processing comprising embedding the service page into a page corresponding to the transaction request.

Claims

1. A method of implementing network transactions based on Open Application Programming Interface (API), the method comprising:

receiving a first invocation request to invoke an Open API from a third party development server according to a user'"'"'s transaction request;

determining an Internet Service Provider (ISP) server corresponding to the Open API as requested to be invoked in the invocation request;

sending the first invocation request to the determined ISP server;

receiving a service page returned by the ISP server according to the first invocation request; and

sending the service page to the third party development server for processing the service page and sending the processed service page to the user, the processing comprising embedding the service page into a page corresponding to the transaction request.

2. The method as recited in claim 1, wherein in an event that the Open API as requested to be invoked comprises a plurality of Open APIs, then before sending the first invocation request to the determined ISP server, the method further comprises:

determining an invocation relationship among the plurality of Open APIs; and

sending the first invocation request to the determined ISP server, the sending comprising;

in an event that an invocation sequence exists among the plurality of Open APIs according to the invocation relationship, sending the first invocation request to an ISP server corresponding to a first Open API which is first-ranked in the invocation sequence of the plurality of Open APIs; and

in an event that an invocation sequence does not exist among the plurality of Open APIs according to the invocation relationship, sending the first invocation request to a plurality of ISP servers each of which corresponding to a respective one of the plurality of Open APIs.

3. The method as recited in claim 2, wherein in an event that an invocation sequence exists among the plurality of Open APIs according to the invocation relationship, then before sending the service page to the third party development server, the method further comprises:

embedding in the service page the invocation sequence of the plurality of Open APIs.

4. The method as recited in claim 3, further comprising:

receiving a second invocation request to invoke a second Open API which is after the first Open API according to the invocation sequence and embedded in the service page;

sending the second invocation request to an ISP server corresponding to the second Open API;

receiving a service page from the ISP server corresponding to the second Open API according to the second invocation request; and

sending the service page to the third party development server to process the service page by the third party development server and send the processed service page to the user.

5. The method as recited in claim 4, wherein before sending the second invocation request to an ISP server corresponding to the second Open API, the method further comprises:

determining, according to the invocation relationship among the plurality of Open APIs, that the second Open API needs to be invoked through the first Open API;

sending the second invocation request to the ISP server corresponding to the second Open API; and

receiving a service page from the ISP server corresponding to the second Open API in response to the second invocation request by;

sending, from an ISP server corresponding to the first Open API the sending invocation request to the ISP server corresponding to the second Open API; and

receiving a processed service page from the ISP server corresponding to the first Open API, the service page being received by the ISP server corresponding to the first Open API from the ISP server corresponding to the second Open API, the service page being embedded in a service page of the ISP server corresponding to the second Open API.

6. The method as recited in claim 1, wherein embedding the service page into a page corresponding to the transaction request comprises:

embedding the service page in the page corresponding to the transaction request in a form of Iframe.

7. The method as recited in claim 1, wherein before determining an ISP corresponding to the Open API as requested to be invoked in the invocation request, the method further comprises:

authenticating the user who sends the transaction request.

8. The method as recited in claim 7, wherein authenticating the user who sends the transaction request comprises:

creating a user login identification when the user logs in successfully; and

determining whether the user login identification is valid when the user login identification is updated each time when the user sends a respective transaction request.

9. The method as recited in claim 1, wherein in an event that the determined ISP server corresponding to the Open API as requested to be invoked in the invocation request comprises a plurality of ISP servers, sending the first invocation request to the determined ISP server comprises:

employing a random route algorithm to locate one of the determined ISP servers; and

sending the first invocation request to the located one of the determined ISP servers.

10. An apparatus of implementing network business based on Open Application Programming Interface (API), comprising:

a first receiving unit that receives an invocation request to invoke an Open API sent by a third party development server according to a user'"'"'s business request;

a first ISP invocation unit that determines an Internet Service Provider (ISP) server corresponding to the Open API as requested to be invoked in the invocation request received by the first receiving unit, and sends the invocation request to the determined ISP server; and

a first invocation result feedback unit that receives a service page returned from the ISP server according to the invocation request sent by the first ISP invocation unit, and sends the service page to the third party development server for processing the service page and sending the processed service page to the user, the processing comprising embedding the service page into a page corresponding to the business request.

11. The apparatus as recited in claim 10, wherein the first ISP invocation unit comprises:

an invoke relationship determination module that determines an invocation relationship among a plurality of Open APIs in an event that the Open API as requested to be invoked in the invocation request received by the first receiving unit comprises the plurality of Open APIs;

a first invocation execution module that sends the invocation request to an ISP server corresponding to a first Open API which is in a first place of an invocation sequence of the plurality of Open APIs in an event that the invoke sequence is determined to exist among the plurality of Open APIs according to the invocation relationship determined by the invocation relationship determination module; and

a second invocation execution module that sends the invocation request to a plurality of ISP servers individually corresponding to the plurality of Open APIs in an event that the invocation sequence is determined not to exist among the plurality of Open APIs according to the invocation relationship determined by the invocation relationship determination module.

12. The apparatus as recited in claim 11, further comprising:

an invoke relationship embedding unit that embeds the invocation relationship among the plurality of Open APIs to the service page in an event that the invocation sequence is determined to exist among the plurality of Open APIs according to the invocation relationship, and provides the embedded and processed service page to the first invocation result feedback unit.

13. The apparatus as recited in claim 12, further comprising:

a second receiving unit that receives an invocation request to invoke a second Open API which is after the first Open API and is triggered according to the invocation sequence embedded in the service page returned by the first invocation result feedback unit;

a second ISP invocation unit that sends the invocation request received by the second receiving unit to an ISP server corresponding to the second Open API; and

a second invocation result feedback unit that receives a service page returned from the ISP server corresponding to the second Open API according to the invocation request according to the second ISP invoke unit, and sends the service page to the third party development server for processing the service page and sending the processed service page to the user.

14. The apparatus as recited in claim 13, wherein the second ISP invocation unit comprises:

an invocation relationship analysis module that determines whether the second Open API should be invoked through the first Open API according to the invocation relationship among the plurality of Open APIs before sending the invocation request received by the second receiving unit to an ISP server corresponding to the second Open API; and

an invocation request sending module that forwards the invocation request to an ISP server corresponding to the second Open API in an event that an analysis result of the invocation relationship analysis module is positive;

wherein the second invocation result feedback unit comprises;

a receiving module that receives a service page processed and returned by the ISP server corresponding to the first Open API, wherein the service page is the service page returned by the ISP server corresponding to the second Open API and received by the ISP server corresponding to the first Open API which embeds in the service page provided by the first Open API; and

a feedback module that sends the service page received by the receiving module to the third party development server for processing the service page and sending the processed service page to the user.

15. The apparatus as recited in claim 10, further comprising:

an authentication unit that authenticates the user who sends the business request, and instructs the first ISP invocation unit to determine an ISP corresponding to Open API as requested to be invoked in the invocation request.

16. The apparatus as recited in claim 15, wherein the authentication unit comprises:

an authentication module that determines the user authentication in an event that the user meets a setting condition, wherein the setting condition comprises;

creating a user login certification when the user logs in successfully; and

determining the user login certification is valid, wherein the user login certification is updated each time when the user sends a business request; and

an instruction module that instructs the first ISP invocation unit to determine an ISP corresponding to the Open API as requested to be invoked in the invocation request in an event that the authentication module determines the user is authenticated.

17. The apparatus as recited in claim 10, wherein the first ISP invoke unit comprises:

an ISP server determination module that determines a quantity of ISPs corresponding to the Open API as requested to be invoked in the invocation request; and

an ISP server selection module that employs a random route algorithm to locate an ISP server in a plurality of ISP servers if the ISP determined by the ISP server determination module comprises the plurality of ISPs, and sends the invocation request to the located ISP server.

18. A system of implementing network transaction based on Open Application Programming Interface (API), the system comprising:

a third party development server;

a transaction implementation server; and

an ISP server, wherein

the third party development server sends an invocation request to an Open API to the transaction implementation server according to a user'"'"'s transaction request, receives a service page returned from the transaction implementation server, and embeds the service page into a page corresponding to the transaction request before providing to the user;

the transaction implementation server determines an Internet Service Provider (ISP) server corresponding to the Open API as requested in the invocation request in response to the invocation request, sends the invocation request to the determined ISP server, receives a service page returned by the ISP server, and sends the service page to the third party development server; and

the ISP server returns a corresponding service page to the transaction implementation server according to the invocation request sent by the transaction implementation server.