Результат интеллектуальной деятельности: УСТРОЙСТВО И СПОСОБ ДЛЯ ОБРАБОТКИ МНОЖЕСТВА ОТКРЫТЫХ API

Область техники, к которой относится изобретение

[1] Настоящее раскрытие относится к устройству и способу для обработки открытого интерфейса прикладного программирования (API). Более конкретно, настоящее раскрытие относится к устройству и способу для множественной обработки открытых API блока независимой функции на основе платформы открытого API.

Предшествующий уровень техники

[2] Способ предоставления открытого интерфейса прикладного программирования (API), основанного на web-услугах, отвечающий родственной области техники, реализует и предоставляет функции API, опубликованные на сервере открытого API как независимые функции. С помощью способа, отвечающего родственной области техники, клиент делает запрос интерфейса требуемой функции API в соответствии со стандартом межсетевого взаимодействия и принимает результирующее (возвратное) значение соответствующей функции API в виде расширяемого языка маркировки (XML).

[3] Однако при рассмотрении API поиска способ обработки API, отвечающий родственной области техники, имеет относительно длительное время ответа. Например, выборочный поиск API в базе данных (DB) является зависимым от времени запроса DB, и, таким образом, используемость уменьшается. Кроме того, API родственной области техники может иметь последовательность запроса API (например, регистрация подарочной карты -> поиск списка -> подробный поиск) в соответствии с потоком услуг. В этом случае API последовательно обрабатывается в соответствии с последовательностью запроса и, следовательно, время обработки становится длиннее. Кроме того, платформа открытого API, отвечающая родственной области техники, предоставляет только ответ на запрос 1:1 (например, API выполняют независимые функции и реализуют независимые интерфейсы, соответственно). Таким образом, имеется потребность в улучшенном устройстве и способе для множественной обработки открытых API независимой функции посредством только однократного вызова.

[4] Вышеупомянутая информация предоставлена только как информация предыстории, чтобы помочь пониманию настоящего раскрытия. Не сделано никакого определения и не сделано никакого утверждения относительно того, могло ли быть применимым любое из вышеупомянутого как предшествующий уровень техники относительно настоящего раскрытия.

Раскрытие изобретения

Техническая проблема

[5] При рассмотрении API поиска способ обработки API, отвечающий родственной области техники, имеет относительно длительное время ответа. Кроме того, платформа открытого API, отвечающий родственной области техники, предоставляет только ответ на запрос 1:1 (например, API выполняют независимые функции и реализуют независимые интерфейсы, соответственно). Таким образом, имеется потребность в улучшенном устройстве и способе для множественной обработки открытых API независимой функции посредством только однократного вызова.

Решение проблемы

[6] Аспекты настоящего раскрытия направлены на, по меньшей мере, вышеупомянутые проблемы и/или недостатки и предоставляют, по меньшей мере, преимущества, описанные ниже. Таким образом, аспектом настоящего раскрытия предоставляются устройство и способ для множественной обработки открытых интерфейсов прикладного программирования (API) независимой функции посредством только однократного вызова. С этой целью клиент, в соответствии с вариантом осуществления настоящего раскрытия, передает открытый API, включающий в себя заголовок протокола передачи гипертекста (HTTP), который может вызвать множество родственных API, в сервер открытых API и делает запрос обработки множества открытых API. Кроме того, сервер открытых API проверяет интерфейс функции (N) API, реализованный в блоке действительных независимых функций, и информацию заголовка и сохраняет проверенные интерфейс функции (N) API и информацию заголовка во временной памяти и передает сохраненное результирующее значение API, когда запрашивается передача соответствующего открытого API.

[7] В соответствии с аспектом настоящего раскрытия, предоставлен способ обработки множества API сервером API. Способ включает в себя прием сообщения запроса первого API из терминала, причем сообщение запроса включает в себя информацию относительно одного или более вторых API, ассоциированных с первым API, идентификацию одного или более вторых API с помощью анализа данной информации, поиск результирующих данных первого API и одного или более вторых API в базе данных, сохранение результирующих данных одного или более вторых API и передачу сообщения ответа, включающего в себя результирующие данные первого API, в терминал.

[8] В соответствии с другим аспектом настоящего раскрытия, предоставлен способ обработки множества API устройством терминала. Способ включает в себя передачу сообщения запроса первого API в сервер API, причем сообщение запроса включает в себя информацию относительно одного или более вторых API, ассоциированных с первым API, и прием сообщения ответа, включающего в себя результирующие данные первого API, из сервера API, причем сервер API обрабатывает и сохраняет результирующие данные вторых API после передачи сообщения ответа первого API.

[9] В соответствии с другим аспектом настоящего раскрытия, предоставлено устройство сервера API, обрабатывающее множество API. Устройство сервера API включает в себя виртуальный уровень API, сконфигурированный с возможностью приема сообщения запроса первого API, включающего в себя информацию относительно одного или более вторых API, ассоциированных с первым API, переданных из терминала, анализа информации, чтобы идентифицировать один или более вторых API, поиска и обработки результирующих данных первого API и одного или более вторых API в базе данных и передачи сообщения ответа, включающего в себя результирующие данные первого API, в терминал, функции API, сконфигурированные с возможностью поиска результирующих данных начального API и API соединения в базе данных и генерации результирующих данных под управлением виртуального уровня API, и память, сконфигурированную с возможностью сохранения результирующих данных и API соединения под управлением виртуального уровня API.

[10] Как описано выше, настоящее раскрытие предоставляет способ для множественной обработки открытых API независимых функций посредством только однократного вызова и, в частности, предварительно обрабатывает открытый API, имеющий относительно длительное время ответа, чтобы заранее иметь данные возврата, и возвращает результирующее значение без запрашивания DB, когда имеется реальный запрос, таким образом, обеспечивая тот же результат, что и результат кэш-памяти. Несмотря на то, что кэш-память имеет медленное время ответа, поскольку она делает реальный запрос в первом запросе, настоящее раскрытие обеспечивает быстрое время ответа, даже в первом запросе реального запроса посредством параллельной предварительной обработки.

[11] Другие аспекты, преимущества и характерные признаки раскрытия станут понятными специалистам в данной области техники из следующего подробного описания, которое, взятое совместно с прилагаемыми чертежами, раскрывает различные варианты осуществления настоящего раскрытия.

Краткое описание чертежей

[12] Вышеупомянутые и другие аспекты, признаки и преимущества определенных вариантов осуществления настоящего раскрытия станут более понятными из следующего описания, взятого совместно с сопровождающими чертежами, на которых:

[13] Фиг.1 - блок-схема, иллюстрирующая клиент и сервер в соответствии с вариантом осуществления настоящего раскрытия;

[14] Фиг.2 - блок-схема последовательности этапов, иллюстрирующая процедуру обработки интерфейса прикладного программирования (API) клиента в системе обработки API, такой как клиент 110 в системе обработки API, имеющий структуру, как изображено на фиг.1, в соответствии с вариантом осуществления настоящего раскрытия;

[15] Фиг.3 - блок-схема последовательности этапов, иллюстрирующая процедуру обработки API сервера в системе обработки API, такой как сервер 120 в системе обработки API, имеющий структуру, как изображено на фиг.1, в соответствии с вариантом осуществления настоящего раскрытия;

[16] Фиг.4 - блок-схема последовательности этапов, иллюстрирующая процедуру обработки начального API из множества API между клиентом и сервером API в соответствии с вариантом осуществления настоящего раскрытия;

[17] Фиг.5 - блок-схема последовательности этапов, иллюстрирующая процедуру обработки API соединения из множества API между клиентом и сервером API в соответствии с вариантом осуществления настоящего раскрытия;

[18] Фиг.6 иллюстрирует пример обработки регистрации подарочной карты и процедуры поиска списка посредством множества API в соответствии с вариантом осуществления настоящего раскрытия;

[19] Фиг.7 иллюстрирует процедуру для автоматического выпуска подарочной карты конечного продвижения посредством множества API в соответствии с вариантом осуществления настоящего раскрытия.

[20] По всем чертежам, следует заметить, что одинаковые ссылочные номера используются сквозным образом для обозначения одинаковых или подобных элементов, признаков и структур.

Варианты осуществления изобретения

[21] Следующее описание со ссылкой на сопровождающие чертежи предоставлено, чтобы помочь в полном понимании различных вариантов осуществления настоящего раскрытия, как определено формулой изобретения и ее эквивалентами. Оно включает в себя различные специфические детали, чтобы помочь в этом понимании, но они должны рассматриваться только как иллюстративные. Таким образом, обычные специалисты в данной области техники поймут, что различные изменения и модификации различных вариантов осуществления, описанных в настоящем раскрытии, могут быть сделаны, не выходя за рамки объема и сущности настоящего раскрытия. Кроме того, описания широко известных функций и конструкций могут быть пропущены для ясности и краткости.

[22] Термины и слова, используемые в следующем описании и в формуле изобретения, не должны ограничиваться библиографическими значениями, но просто используются изобретателем, чтобы дать возможность полного и последовательного понимания настоящего раскрытия. Таким образом, специалистам в данной области техники должно быть понятно, что следующее описание различных вариантов осуществления настоящего раскрытия предоставлено только с целью иллюстрации, а не с целью ограничения настоящего раскрытия, как определено прилагаемой формулой изобретения и ее эквивалентами.

[23] Следует понимать, что формы единственного числа включают в себя множественные объекты, если контекст ясно не указывает обратное. Таким образом, например, ссылка на "поверхность компонента" включает в себя ссылку на одну или более таких поверхностей.

[24] Обычно интерфейс прикладного программирования (API) имеет язык или тип сообщения, используемые, когда прикладная программа осуществляет связь с системной программой, такой как операционная система или система управления базой данных. API реализуется с помощью вызова функции, обеспечивающей соединение с конкретной подпрограммой для исполнения в программе. Таким образом, один API имеет несколько программных модулей или подпрограмм, которые уже существуют или должны соединяться, чтобы выполнять операцию, запрашиваемую с помощью вызова функции. Открытый API относится к опубликованным API, которые позволяют пользователю интернета получать результат поиска web и пользовательский интерфейс (UI), а также непосредственно разрабатывать прикладную программу и услугу.

[25] В следующем описании термин "открытый API" обозначает открытый интерфейс разработки приложения, а понятие "платформа открытого API" обозначает платформу с общим ядром для разработки услуг. Следующее описание будет сделано на основе web-услуги открытого API схемы представительной передачи состояния (REST) между простым протоколом доступа к объекту (SOAP) и схемами REST как представительной схемы связи, использующей протокол передачи гипертекста (HTTP) открытого API, который появился согласно парадигме Web 2.0. SOAP использует запрос сообщения SOAP и технологию возврата, а REST использует запрос унифицированного указателя ресурса (URL), возврат расширяемого языка маркировки (XML) и технологию поверх HTTP.

[26] В случае, когда клиент делает запрос множества открытых API, включающих в себя начальный API и API соединения, при обработке API, если клиент вставляет информацию заголовка API соединения в начальный API и делает запрос начального API, сервер анализирует информацию заголовка в соответствии с запросом начального API, вызывает начальный API и API соединения, сохраняет их результирующие значения и передает идентификатор транзакции API соединения в клиент совместно с результирующим значением начального API. После этого, когда клиент вызывает API соединения, клиент также вызывает соответствующий идентификатор транзакции, и сервер API осуществляет доступ к сохраненному результирующему значению API соединения, соответствующему идентификатору транзакции, чтобы ответить клиенту. Таким образом, когда клиент делает запрос начального API, сервер API вызывает заранее и сохраняет результирующие значения API соединения. В результате, сервер API может немедленно передать сохраненное результирующее значение, когда клиент делает запрос API соединения (реальный запрос) и, следовательно, гарантирует быстрое время ответа API.

[27] В следующем описании термин "первый API" используется как имеющий то же значение, что и начальный API, а термин "второй API" используется как имеющий то же значение, что и API соединения. Кроме того, информация относительно второго API, включенная в сообщение запроса первого API, может быть форматом заголовка.

[28] Фиг.1 - блок-схема, иллюстрирующая клиент и сервер в соответствии с вариантом осуществления настоящего раскрытия.

[29] Ссылаясь на фиг.1, клиент 110 является устройством, делающим запрос открытого API, и включает в себя модуль запроса API. Когда запрошенный API соответствует множеству открытых API, клиент 110 также делает запрос информации заголовка множества открытых API (далее в настоящем раскрытии упоминаемых как API соединения или второй API), подсоединяемых, когда запрашивается первый API (т.е. начальный API).

[30] Клиент 110 может быть устройством терминала и может включать в себя устройство связи, устройство памяти, контроллер и тому подобные. Контроллер может включать в себя модуль запроса API. Устройство связи передает/принимает сообщение запроса и ответа API в/из сервера 120 API. То есть, устройство связи передает сообщение запроса первого API, включающее в себя информацию относительно одного или более вторых API, соединенных с первым API, сгенерированное контроллером, в сервер API, принимает сообщение ответа, переданное из сервера API, и выводит сообщение ответа в контроллер. Устройство памяти сохраняет сообщение ответа первого API под управлением контроллера. Контроллер генерирует сообщение запроса, делающее запрос первого API, и выводит сообщение запроса в устройство связи. Когда устройство связи принимает сообщение ответа, включающее в себя результирующие данные первого API, устройство связи сохраняет информацию идентификации второго API, включенную в сообщение ответа, в устройстве памяти.

[31] Контроллер вставляет информацию относительно второго API в сообщение запроса первого API, и информация относительно второго API может включать в себя параметр, указывающий то, выполняется ли множественная обработка, параметр, указывающий схему множественной обработки, имя параметра соединения, пользователя параметра соединения, имя устройства и тому подобное. При этом сервер 102 API генерирует сообщение ответа первого API, включающее в себя информацию идентификации (например, ID транзакции), соответствующую каждому из вторых API, и передает сгенерированное сообщение ответа первого API клиенту 110.

[32] Клиент 110 генерирует сообщение запроса второго API, включающее в себя информацию идентификации (например, ID транзакции) соответствующего второго API из устройства памяти, и выводит сгенерированное сообщение запроса второго API в устройство связи. Устройство связи передает сообщение запроса второго API в сервер 120 API.

[33] Сервер 120 API может включать в себя интерфейс 160 функции (N) API, реализованный в блоке действительных независимых функций, виртуальный уровень 150 API для проверки информации заголовка и сохранения информации заголовка во временной памяти, и временную память (или память) 170. Когда клиент 110 делает запрос множества открытых API, сервер 120 API идентифицирует информацию заголовка открытых API соединения, вызывает результирующие значения начального открытого API и открытых API соединения и сохраняет результирующие значения открытых API соединения. Когда результирующее значение начального открытого API получено, сервер 120 API также передает ID транзакций открытых API соединения. Кроме того, когда делается запрос открытого API соединения, ID транзакции идентифицируется без вызова базы данных 130, а сохраненное результирующее значение соответствующего API передается клиенту.

[34] База 130 данных является хранилищем, которое сохраняет действительные данные API.

[35] Фиг.2 - блок-схема последовательности этапов, иллюстрирующая процедуру обработки API клиента в системе обработки API, такой как клиент 110 в системе обработки API, имеющий структуру, как изображено на фиг.1, в соответствии с вариантом осуществления настоящего раскрытия, и фиг.3 - блок-схема последовательности этапов, иллюстрирующая процедуру обработки API сервера в системе обработки API, такой как сервер 120 в системе обработки API, имеющий структуру, как изображено на фиг.1, в соответствии с вариантом осуществления настоящего раскрытия.

[36] Ссылаясь на фиг.2, когда API вызывается, клиент 110 обнаруживает вызов в операции 211 и идентифицирует то, соответствует ли вызванный API множеству API, в операции 213. Когда вызванный API соответствует множеству API, клиент 110 обнаруживает его в операции 213 и генерирует заголовок API соединения в операции 215. На фиг.1 допускается, что множество открытых API включают в себя API_A и API_B, API_A является начальным API, а API_B является API соединения. В этом случае клиент 110 генерирует заголовок API соединения в операции 215, структура заголовка API соединения является такой, как изображено в таблице 1 ниже.

[37]

Таблица 1

[38] В таблице 1, приведенной выше, "x-ssp-multiple-api" - параметр, указывающий то, соответствует ли вызванный API множеству API. Когда "x-ssp-multiple-api" является включенным (ON), он относится к API соединения множества API. "x-ssp-multiple-api-method" - параметр, указывающий способ обработки множества API. Link относится к API, который выполняет последовательную обработку (serial processing), а parallel относится к API, который выполняет параллельную обработку (parallel processing) независимо от любой последовательности. "x-ssp-multiple-api-1-name" обозначает имя API соединения (имя API запроса, например, API_B на фиг.1), "x-ssp-multiple-api-1-param1" обозначает ID пользователя, а "x-ssp-multiple-api-1-param2" обозначает ID устройства. "x-ssp-transactionid" - идентификатор, указывающий, что сервер 120 API временно сохраняет результирующее значение API соединения? и может быть информацией, принятой из сервера 120 API.

[39] После генерации заголовка API соединения, как описано выше, клиент 110 вставляет заголовок API соединения в сообщение запроса начального API, делает запрос начального API в сервер 120 API (запрос API_A + заголовок API_B) и ждет ответа. Когда сервер 120 API принимает запрос множества API от клиента 110, сервер 120 API делает запрос результирующих значений множества API в базу 130 данных, временно сохраняет результирующее значение API_B, т.е. DATA_B между результирующими значениями (DATA_A DATA_B), генерирует результирующее значение DATA_A API_A и ID транзакции API_B как сообщение ответа и передает сгенерированное сообщение ответа клиенту 110. ID транзакции может быть информацией о позиции памяти, которая сохраняет результирующее значение API_B, соответствующее DATA_B. Клиент 110 обрабатывает результирующее значение DATA_A API_A из сообщения ответа API_A, принятого в операции 219, и сохраняет ID транзакции API_B, соответствующего API соединения. Таким образом, клиент 110 добавляет информацию заголовка API соединения к начальному API и передает начальный API при обработке множества API, и соотносит ID транзакций API соединения с соответствующими API при приеме сообщения ответа.

[40] Когда клиент 110 обнаруживает вызов API соединения, клиент 110 обнаруживает вызов в операции 221 и генерирует сообщение запроса API соединения, и делает запрос API соединения в сервер 120 API в операции 223. При этом сообщение запроса API_B, соответствующего API соединения, является сообщением (запрос API_В + заголовок (ID транзакции_B)), включающим в себя ID транзакции. Сервер 120 API идентифицирует ID транзакции при приеме сообщения запроса API соединения, осуществляет доступ к результирующим данным DATA_B соответствующего API соединения (API_В) во временной памяти 170 и передает результирующее значение как сообщение ответа. В этом случае сервер 120 API не выполняет операцию выполнения запроса результирующего значения API соединения в базу 130 данных, и, таким образом, можно уменьшить время ответа. По существу, клиент 110 может принять результирующее значение API соединения за меньшее время в операции 225.

[41] Однако, когда вызванный API не соответствует множеству API или API соединения, клиент 110 обнаруживает, что API является API, имеющим независимую функцию, в операции 221, генерирует и передает сообщение запроса API в операции 231 и принимает и обрабатывает сообщение ответа, переданное из сервера 120 API, в операции 233.

[42] Ссылаясь на фиг.3, когда сервер 130 API принимает сообщение запроса API от клиента 110, сервер 130 API обнаруживает прием в операции 311 и выполняет синтаксический анализ заголовка сообщения запроса API, чтобы анализировать API, в операции 313. В это время, когда сообщение запроса API включает в себя заголовок API соединения (т.е. x-ssp-multiple-api является включенным (ON)), сервер 130 API обнаруживает, что API соответствует множеству API в операции 313, и анализирует заголовок API соединения в операции 315. Сервер 120 API делает запрос результирующих значений начального API и API соединения в базу 130 данных в операции 317. Кроме того, сервер 120 API временно сохраняет результирующее значение (в данном случае DATA_B) во временной памяти 170 и генерирует ID транзакции API соединения в операции 319. ID транзакции включает в себя информацию о позиции временной памяти, которая сохраняет результирующее значение API соединения. Сервер 120 API передает результирующее значение начального API (API_A) и результирующее значение, включающее в себя ID транзакции (DATA_A, ответ API_A (XMR + ID транзакция (транзакции) (API_В)), клиенту 110.

[43] Когда сообщение запроса API, принятое от клиента 110, соответствует API соединения, сервер 120 API обнаруживает его в операции 331, идентифицирует ID транзакции в заголовке сообщения запроса API в операции 333, осуществляет доступ к результирующему значению API соединения во временной памяти, расположенной в позиции, соответствующей идентифицированному ID транзакции, и передает результирующее значение API соединения клиенту 110 как сообщение ответа (DATA_B, ответ API_В (XML)) в операции 335. Таким образом, результирующее значение API соединения может предоставляться немедленно, когда запрашивается API соединения, поскольку результирующее значение API соединения уже было вызвано, когда был обработан начальный API, связанный с API соединения. Следовательно, сервер 120 API может выполнять множественную обработку открытых API независимых функций посредством однократного вызова, когда запрашиваются множество API, и может передать результат предварительно обработанного API клиенту немедленно, когда API вызывается. В результате, время ответа может быть улучшено.

[44] Однако, когда API не соответствует множеству API или API соединения, сервер 120 API обнаруживает это в операции 331, вызывает соответствующее результирующее значение API из базы 130 данных в операции 341 и передает другое результирующее значение API клиенту 110 как сообщение ответа в операции 343.

[45] Фиг.4 и 5 - блок-схемы последовательности этапов, иллюстрирующие процедуры обработки множества API между клиентом и сервером API в соответствии с вариантом осуществления настоящего раскрытия. Фиг.4 - блок-схема последовательности этапов, иллюстрирующая процедуру обработки начального API множества API между клиентом и сервером API в соответствии с вариантом осуществления настоящего раскрытия, а фиг.5 - блок-схема последовательности этапов, иллюстрирующая процедуру обработки API соединения множества API между клиентом и сервером API в соответствии с вариантом осуществления настоящего раскрытия.

[46] Ссылаясь на фиг.4, клиент определяет, в заголовке, API соединения, обрабатываемые множественным способом с помощью API (начального API), который должен запрашиваться первым, когда запрашиваются множество API, и делает запрос передачи начального API, включающего в себя заголовок API соединения, в операции 411. Когда начальный API является API_А, API соединения является API_В, методом множества API является метод link, ID пользователя является w023ndn2ds, ID устройства является 352099011383729, сообщение запроса множества API API_А, соответствующего запросу API_А (+заголовок), может иметь конфигурацию, как изображено в таблице 2 ниже.

[47]

Таблица 2

[48] Виртуальный уровень 150 API сервера API (сервера открытого API) 120 анализирует сообщение запроса API, переданное от клиента 110, чтобы идентифицировать то, соответствует ли сообщение запроса API сообщению запроса множества API, в операции 413. То есть виртуальный уровень 150 идентифицирует то, находится ли x-ssp-multiple-api во включенном (ON) состоянии в заголовке сообщения запроса, и определяет то, выполнять ли множественную обработку. При этом, когда x-ssp-multiple-api находится в выключенном (OFF) состоянии, виртуальный уровень 150 API обнаруживает выключенное (OFF) состояние в операции 413 и делает запрос API_А в отношении функций 160 API в операции 415. Функции 160 API осуществляют доступ к результирующему значению API_А в базе 130 данных и передают сообщение ответа API_А клиенту 110. То есть, когда x-ssp-multiple-api находится в выключенном (OFF) состоянии, сервер 120 API не выполняет множественную обработку и передают сообщение ответа для запроса API_А (запроса 1-го API) клиенту 110.

[49] Однако, когда x-ssp-multiple-api находится во включенном (ON) состоянии, виртуальный уровень 150 API обнаруживает включенное (ON) состояние в операции 413 и генерирует надлежащий ID транзакции соответствующего запроса в операции 421. То есть, виртуальный уровень 150 API генерирует ID транзакции (в данном случае "API_B_Т201303133425500") API соединения (API_В) в операции 421.

[50] Виртуальный уровень 150 проверяет способ множественной обработки [50] в операции 423. Метод множества API может использовать метод link (последовательная обработка) и метод parallel (параллельная обработка). Метод link относится к способу обработки API обработки начального API и API соединения в последовательном порядке (обработка API_А -> API_В -> API_C), а метод parallel относится к способу обработки API параллельно, независимо от последовательностей множества API. Например, множество API в методе link может быть множеством API, имеющим последовательный порядок обработки API, как регистрация -> поиск -> запрос подробной информации. Например, допускается, что множество API включают в себя API_А, API_В и API_С, и API_В и API_С являются API соединения API_А. В этом случае когда x-ssp-multiple-api-method заголовка соответствует parallel, виртуальный уровень 150 API одновременно вызывает API_А, API_В и API_С, и функции 160 API осуществляют выборку результирующих значений API из базы 130 данных, независимо от последовательности из трех API, в операции 425. Однако, когда x-ssp-multiple-api-method заголовка соответствует link, виртуальный уровень 150 API осуществляет управление так, чтобы сначала вызвать и обработать API_А и API_В в операции 427, и вызвать и обработать API_С в операции 429. Когда обработка API_А заканчивается, виртуальный уровень 150 API генерирует сообщение ответа API_А и передает сгенерированное сообщение ответа клиенту 110. Сообщение ответа API_А может быть результирующими данными (XML) API_А и ID транзакции API соединения, сгенерированным в операции 421 (ответ API_А + ID (множество ID) транзакции). Когда множество API включают в себя API_А и API_В, а ID транзакции API_В является API_В_Т201303133425500, таблица 3, приведенная ниже, и сообщение ответа API_А передается клиенту 110. Клиент 110 принимает и обрабатывает сообщение ответа (DATA_A, XML) API_А, а также сохраняет API соединения (в данном случае ID транзакции API_В, соответствующий API_В_Т201303133425500), в операции 431.

[51]

Таблица 3

[52] Виртуальный уровень 150 API принимает результирующие данные API соединения (API_В и API_С), обработанные функциями 160 API, и сохраняет результирующие данные API соединения в памяти 170 в операциях 433 и 435. При этом память 170 может быть памятью или локальным диском.

[53] Ссылаясь на фиг.5, когда API соединения вызывается в будущем, клиент 110 передает сообщение запроса API соединения в сервер 120 API в операции 511. Когда API соединение является API_В, клиент 110 вставляет ID транзакции API_B (API_В_Т201303133425500) в сообщение запроса API_В. Запрос API_В (заголовок: TID), переданный в сервер 120 API от клиента, может иметь конфигурацию таблицы 4, приведенной ниже.

[54]

Таблица 4

[55] Виртуальный уровень 150 API сервера 120 API проверяет заголовок API_В, чтобы идентифицировать то, имеется ли x-ssp-transactionid, в операции 513 (существует заголовок; x-ssp-transactionid?). Когда нет x-ssp-transactionid, сервер 120 API выполняет операции 551 и 553, чтобы осуществить выборку результирующих данных API_В из базы 130 данных и передать результирующие данные клиенту 110. Однако, когда имеется x-ssp-transactionid в заголовке API_В в операции 513, виртуальный уровень 150 API проверяет то, имеются ли результирующие данные, соответствующие x-ssp-transactionid, в памяти 170 (искать данные (XML) по идентификатору(ам) транзакции?) в операции 515. Когда нет результирующих данных, сервер 120 API выполняет операции 555 и 557, чтобы осуществить выборку результирующих данных API_В из базы 130 данных и передать результирующие данные клиенту 110. Однако, когда имеются результирующие данные, соответствующие ID транзакции, в памяти 170 в операции 515, виртуальный уровень 150 API обнаруживает результирующие данные в операции 515, осуществляет выборку результирующих данных (DATA_B, XML) API_В из памяти 170 API в операции 517 и генерирует сообщение ответа API_В и передает сообщение ответа API_В клиенту 110 в операции 519. В этом случае сервер 120 API генерирует сообщение ответа предварительно обработанного API, не вызывая базу данных 130, и, таким образом, может увеличить скорость ответа API. При этом сообщение ответа API_В может иметь конфигурацию, изображенную в таблице 5 ниже.

[56]

Таблица 5

[57] Как описано выше, операция обработки между клиентом 110 и сервером 120 API в соответствии с вариантом осуществления настоящего раскрытии выполняется следующим образом. При обработке множества API клиент 110 определяет заголовки API соединения, в отношении которых должна быть выполнена множественная обработка, в сообщении запроса начального API, когда запрашивается начальный API (1-й запрос). При этом заголовки генерируются в количестве, равном количеству API соединения, и заголовки API соединения могут включать в себя параметры, такие как x-ssp-multiple-api, x-ssp-multiple-api-method, x-ssp-multiple-api-1-name, x-ssp-multiple-api-1-param1, x-ssp-multiple-api-1-param2 и x-ssp-transactionid, как показано в таблице 1 выше.

[58] Виртуальный уровень 150 API сервера 120 API, принимающий сообщение запроса начального API из множества API, обнаруживает включенное (ON) состояние x-ssp-multiple-api принятых значений заголовка начального API и генерирует надлежащий идентификатор(ы) транзакции соответствующего запроса. Кроме того, виртуальный уровень 150 API проверяет x-ssp-multiple-api-method (т.е. метод обработки) из значения заголовка и делает запрос обработки посредством способа последовательной обработки в функции 160 API, когда метод соответствует "link", и делает запрос обработки посредством способа параллельной обработки в функции 160 API, когда метод соответствует "parallel". Способ последовательной обработки (link) выполняет обработку в последовательности окончание обработки API_А -> окончание обработки API_В ->----> окончание обработки API_N, а способ параллельной обработки (parallel) выполняет одновременную параллельную обработку API_А, API_В,---, API_N. Когда обработка начального API заканчивается (завершается обработка первого запроса), сервер 120 API добавляет идентификатор(ы) транзакции API соединения к результирующему значению ответа начального API и возвращает результирующее значение ответа начального API клиенту 110. Кроме того, когда завершается обработка множества API, сервер 120 API сохраняет результирующие данные (XML) API соединения в памяти 170.

[59] Когда API соединения, обработанные с помощью запроса множественной обработки, запрашиваются в запросе начального API (запрос API предварительной обработки), клиент 110 вставляет идентификатор(ы) транзакции в заголовок запроса API соединения и передает запрос API соединения. Виртуальный уровень 150 API сервера 120 API идентифицирует то, имеется ли x-ssp-transactionid в заголовке запроса API соединения. Когда x-ssp-transactionid имеется, виртуальный уровень 150 API ищет данные с тем же ID в памяти 170 и непосредственно возвращает результирующие данные API соединения клиенту 110.

[60] Таким образом, когда обрабатываются множество API, сервер 120 API может выполнять множественную обработку открытых API, имеющих независимые функции, посредством только однократного вызова клиента 110. В случае, когда обрабатываются множественным способом открытые API, имеющие относительно длительное время ответа, когда клиент 110 делает реальный запрос API соединения, сервер 120 API может передать результирующие данные клиенту как ответ, не запрашивая базу данных 130.

[61] Фиг.6 иллюстрирует пример обработки регистрации подарочной карты и процедуры поиска списка посредством множества API в соответствии с вариантом осуществления настоящего раскрытия.

[62] Ссылаясь на фиг.6, клиент 110 может быть портативным терминалом. Когда кнопка выбора подарочной карты (кнопка добавления на экране 610) выбирается на экране 610 страницы интегрированной оплаты счетов, клиент 110 отображает экран 620 регистрации подарочной карты. В это время, когда пользователь выбирает кнопку регистрации (зарегистрироваться), клиент 110 вызывает множество API для регистрации подарочной карты, как указано с помощью ссылочного номера 650. API регистрации подарочной карты может быть начальным API, а API списка подарочной карты может быть API соединения. В этом случае клиент 110 генерирует информацию заголовка API списка подарочной карты, когда запрашивается API регистрации подарочной карты. Заголовок списка подарочной карты может быть сконфигурирован, как изображено в таблице 6 ниже.

[63]

Таблица 6

[64] Клиент 110 передает запрос множества API (registerGiftCard API) + заголовок (getGiftCardList API) в сервер 120 API, когда вызывается API регистрации подарочной карты. Сервер API генерирует ID транзакции getGiftCardList API и вызывает registerGiftCard API и getGiftCardList API из базы 130 данных. Когда обработка registerGiftCard API завершается, сервер API генерирует ID транзакции getGiftCardList API вместе с результирующими данными (XML) registerGiftCard API как сообщение ответа, передает сообщение ответа и сохраняет результирующие данные getGiftCardList API в памяти 170.

[65] При этом клиент 110, принимающий результирующие данные (XML) getGiftCardList API и ID транзакции getGiftCardList API, сохраняет ID транзакции getGiftCardList API и отображает экран 630 успешной регистрации подарочной карты. Когда пользователь выбирает кнопку ОК на экране 630, клиент 110 вызывает getGiftCardList API, как указано с помощью ссылочного номера 660. Сообщение запроса getGiftCardList API включает в себя ID транзакции ((getGiftCardList API + заголовок (ID транзакции)). Сервер 120 API идентифицирует ID транзакции в сообщении запроса getGiftCardList API, осуществляет выборку результирующих данных getGiftCardList API из памяти и передает ответ клиенту 110. То есть сервер 120 API обнаруживает, что getGiftCardList API соответствует API соединения, осуществляет выборку сохраненных предварительно обработанных результирующих данных getGiftCardList API и немедленно передает ответ клиенту 110 без вызова базы данных. Клиент 110 отображает список подарочной карты на экране 640.

[66] Фиг.7 иллюстрирует процедуру для автоматического выпуска подарочной карты конечного продвижения посредством множества API в соответствии с вариантом осуществления настоящего раскрытия.

[67] Ссылаясь на фиг.7, клиент 110 может быть портативным терминалом. При входе в услугу на отображенном экране 710 конечного продвижения покупки клиент отображает экран 720 и автоматически вызывает API автоматической регистрации конечного продвижения, как указано с помощью ссылочного номера 750. API автоматической регистрации конечного продвижения (regisrergiftCardBulk API) может быть начальным API, а API списка подарочной карты (getGiftCardList API) может быть API соединения. В этом случае клиент 110 генерирует информацию заголовка API списка подарочной карты, когда запрашивается API автоматической регистрации конечного продвижения.

[68] Клиент 110 передает запрос множества API ((regisrergiftCardBulk API + заголовок (getGiftCardList API)) в сервер 120 API, когда вызывается API автоматической регистрации конечного продвижения. Затем сервер API генерирует ID транзакции getGiftCardList API и вызывает regisrergiftCardBulk API и getGiftCardList API из базы 130 данных. Когда обработка getGiftCardList API завершается, сервер API генерирует ID транзакции getGiftCardList API вместе с результирующими данными (XML) regisrergiftCardBulk API как сообщение ответа, передает сообщение ответа и сохраняет результирующие данные getGiftCardList API в памяти 170.

[69] При этом клиент 110, принимающий результирующие данные (XML) regisrergiftCardBulk API и ID транзакции getGiftCardList API, сохраняет ID транзакции getGiftCardList API и отображает экран 730 успешной регистрации подарочной карты. Когда пользователь выбирает кнопку ОК на экране 730, клиент вызывает getGiftCardList API, как указано с помощью ссылочного номера 760. Сообщение запроса getGiftCardList API включает в себя ID транзакции ((getGiftCardList API) + заголовок (ID транзакции)). Сервер 120 API идентифицирует ID транзакции в сообщении запроса getGiftCardList API, осуществляет выборку результирующих данных getGiftCardList API из памяти 170 и передает ответ в клиент 110. То есть, сервер 120 API обнаруживает, что getGiftCardList API соответствует API соединения, осуществляет выборку сохраненных и предварительно обработанных результирующих данных getGiftCardList API и немедленно передает ответ клиенту 110 без вызова базы данных. Клиент 110 отображает список подарочной карты на экране 740.

[70] Несмотря на то, что настоящее раскрытие было изображено и описано со ссылкой на его различные варианты осуществления, специалистам в данной области техники будет очевидно, что различные изменения по форме и в деталях могут быть сделаны в них, не выходя за рамки сущности и объема настоящего раскрытия, как определено прилагаемой формулой изобретения и ее эквивалентами.