Способ и устройство для вызова интерфейса прикладного программирования, носитель информации и электронное устройство Российский патент 2025 года по МПК G06F9/54 

Перекрестная ссылка на родственные заявки

Настоящее описание приводится для заявления приоритета патентной заявки Китая 202010615384.3, поданной 30 июня 2020 г. «Способ и устройство для вызова интерфейса прикладного программирования, носитель информации и электронное устройство», полное содержание которой включено в настоящий документ посредством ссылки.

Область техники

Варианты осуществления настоящего изобретения относятся к области связи и, в частности, к способу и устройству для вызова интерфейса прикладного программирования, носителю информации и электронному устройству.

Уровень техники

В связанных областях техники невозможно динамическое управление диапазоном данных ответа в рамках API. В настоящее время для ответных данных API может реализовываться только статическое управление, то есть разные API определяются для разных диапазонов данных, и вызывающая сторона получает данные из разных диапазонов посредством вызова разных API.

То есть динамическое управление возвращаемыми данными API не реализовано в предшествующем уровне техники.

Сущность изобретения

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

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

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

В соответствии с другим вариантом осуществления настоящего изобретения дополнительно предоставляется компьютерно-читаемый носитель данных, компьютерная программа хранится на компьютерно-читаемом носителе данных, при этом компьютерная программа сконфигурирована для выполнения шагов в любом из предыдущих вариантов осуществления способа.

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

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

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

На фиг. 1 представлена блок-схема аппаратной структуры мобильного терминала способа вызова интерфейса прикладного программирования согласно варианту осуществления настоящего изобретения;

На фиг. 2 представлена блок-схема способа вызова интерфейса прикладного программирования согласно варианту осуществления настоящего изобретения;

На фиг. 3 представлена схема взаимодействия модулей способа вызова интерфейса прикладного программирования согласно варианту осуществления настоящего изобретения;

На фиг. 4 представлена схематическая диаграмма способа вызова интерфейса прикладного программирования согласно варианту осуществления настоящего изобретения;

На фиг. 5 представлена схематическая диаграмма интерфейса дисплея способа вызова интерфейса прикладного программирования согласно варианту осуществления настоящего изобретения;

На фиг. 6 представлена схематическая диаграмма способа вызова интерфейса прикладного программирования согласно варианту осуществления настоящего изобретения;

На фиг. 7 представлена схематическая диаграмма интерфейса дисплея способа вызова интерфейса прикладного программирования согласно варианту осуществления настоящего изобретения;

На фиг. 8 представлена структурная схема устройства вызова интерфейса прикладного программирования согласно варианту осуществления настоящего изобретения;

Подробное описание вариантов осуществления

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

Следует отметить, что термины «первый», «второй» и т.п. в описании, формуле изобретения и чертежах вариантов осуществления настоящего изобретения используются для различения сходных объектов и не должны использоваться для описания определенного порядка или последовательности.

Один из предусмотренных вариантов осуществления способа по настоящей заявке, может быть реализован в мобильном терминале, компьютерном терминале или аналогичном вычислительном устройстве. При реализации на мобильном терминале в качестве примера на фиг. 1 представлена блок-схема аппаратной структуры мобильного терминала способа вызова интерфейса прикладного программирования согласно варианту осуществления настоящего изобретения. Как показано на фиг. 1, мобильный терминал может включать в себя один или несколько (на фиг. 1 показан только один) процессоров 102 (процессор 102 может включать, помимо прочего, устройства обработки, такие как микропрограммный блок управления (MCU) или программируемая пользователем вентильная матрица (FPGA)) и память 104 для хранения данных, при этом мобильный терминал может дополнительно включать в себя передающее устройство 106 для функции связи и устройство ввода/вывода 108. Специалистам в данной области техники очевидно, что структура, показанная на фиг. 1, носит чисто иллюстративный характер и не ограничивает структуру мобильного терминала. Например, мобильный терминал может также включать больше или меньше компонентов, чем показано на фиг. 1, или иметь другую конфигурацию, отличную от показанной на фиг. 1.

Память 104 может использоваться для хранения компьютерной программы, например, программы и модуля прикладного программного обеспечения, например, компьютерной программы, соответствующей способу вызова интерфейса прикладного программирования в вариантах осуществления настоящего изобретения, и процессор 102 выполняет различные функциональные приложения и обработку данных посредством запуска компьютерной программы, хранящейся в памяти 104, то есть реализует способ вызова интерфейса прикладного программирования. Память 104 может включать в себя быстродействующую память с произвольным доступом и может дополнительно включать в себя энергонезависимую память, например, одно или несколько магнитных запоминающих устройств, флэш-память или другие энергонезависимые твердотельные запоминающие устройства. В некоторых случаях память 104 может дополнительно включать запоминающие устройства, расположенные удаленно относительно процессора 102, и эти удаленные запоминающие устройства могут быть соединены с мобильным терминалом посредством сети. В качестве сети может выступать, помимо прочего, Интернет, интранет, локальная сеть, сеть мобильной связи и их комбинации.

Передающее устройство 106 используется для приема или передачи данных посредством сети. Конкретно в качестве сети может выступать беспроводная сеть, предоставляемая поставщиком услуг связи мобильного терминала. В одном случае передающее устройство 106 включает в себя контроллер сетевого интерфейса (Network Interface Controller, сокращенно NIC), который может быть соединен с другими сетевыми устройствами посредством базовой станции для связи с Интернетом. В другом случае передающее устройство 106 может представлять собой радиочастотный модуль (Radio Frequency, сокращенно RF), который используется для связи с Интернетом с помощью беспроводного соединения.

Настоящий вариант осуществления обеспечивает способ вызова интерфейса прикладного программирования. На фиг. 2 представлена диаграмма способа вызова интерфейса прикладного программирования согласно варианту осуществления настоящего изобретения, и, как показано на фиг. 2, процесс включает следующие этапы:

Этап S202, получение запроса вызова первого интерфейса прикладного программирования (API), отправленного целевым приложением, при этом запрос вызова первого API используется для запроса вызова первого API, и запрос вызова первого API содержит первый идентификатор пользователя;

Этап S204, получение первого диапазона данных первого API с предварительной подпиской первого идентификатора пользователя, при этом первый диапазон данных первого API включает в себя первую целевую размерность в соответствии с первым API и целевой параметр в соответствии с первой целевой размерностью;

Этап S206, получение данных ответа первого API, соответствующих первому диапазону данных первого API;

Этап S208, отправка данных ответа первого API в целевое приложение.

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

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

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

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

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

Этап получения запроса вызова первого интерфейса прикладного программирования (API), отправленного целевым приложением, включает получение запроса вызова первого API, отправленного целевым приложением, посредством кода вызова целевого API. Этап получения запроса вызова второго API, отправленного целевым приложением, включает получение запроса вызова второго API, отправленного целевым приложением, посредством кода вызова целевого API.

Перед этапом получения запроса вызова второго API, отправленного целевым приложением, способ дополнительно включает получение второго запроса подписки первого идентификатора пользователя, при этом второй запрос подписки используется для запроса изменения диапазона данных первого API по подписке первого идентификатора пользователя из первого диапазона данных на второй диапазон данных; изменение диапазона данных первого API по подписке первого идентификатора пользователя, с первого диапазона данных на второй.

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

Этап получения запроса вызова первого интерфейса прикладного программирования (API), отправленного целевым приложением, включает получение на шлюзе API запроса вызова первого API, отправленного целевым приложением; этап получения первого диапазона данных первого API с предварительной подпиской первого идентификатора пользователя, включает получение на шлюзе API первого диапазона данных, хранящегося в субмодуле хранения информации о подписках API; этап получения данных ответа первого API, соответствующих первому диапазону данных первого API, включает добавление на шлюзе API первого диапазона данных в качестве управляющей информации в запрос вызова первого API, чтобы получить запрос вызова третьего API; отправку на шлюзе API третьего запроса вызова в модуль предоставления возможностей МЕС; получение на шлюзе API данных ответа первого API, отправленных модулем предоставления возможностей МЕС, при этом модуль предоставления возможностей МЕС используется для запроса данных ответа первого API, соответствующих первому диапазону данных.

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

Исполнительным устройством на предыдущих этапах может быть базовая станция, терминал и т.п., но возможны и другие варианты.

Ниже приведено описание в сочетании с конкретными примерами.

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

Соответствующая система открытия возможностей МЕС обычно использует статический метод для управления данными API и определяет разные API для разных диапазонов данных, используя разные URL-адреса для представления разных диапазонов данных. Пользователь API получает данные разных диапазонов посредством покупки разных API. Например, для данных позиционирования областей А и В необходимо определить два API, например, АРМ определен, а его URL-адрес - {apiroot}/location/v1/area/A, который содержит данные о позиционировании области А; определен API2, а его URL-адрес - {apiroot}/location/v1/area/B, который содержит данные о позиционировании области В. Пользователь API вызывает {apiroot}/location/v1/area/А для подписки на данные области А и {apiroot}/location/v1/area/B для подписки на данные области В. Это вызывает две проблемы, одна из которых заключается в очень большом количестве API-интерфейсов, и один API должен добавляться каждый раз при добавлении области. Вторая проблема заключается в том, что пользователь API, то есть разработчик программы приложения (АРР), должен определить, какой API вызывать при написании кода. Предполагая, что APR подписанное на данные области А, было подключено к сети, то есть в кодах был вызван {apiroot}/location/v1/area/A, и если пользователь API дополнительно подписывается на данные области В после запроса подключения к сети, приложение должно быть переведено в автономный режим, при этом коды повторно модифицируются, вызывается {apiroot}/location/v1/area/B, а затем приложение подключается к сети, так что стоимость разработки приложения увеличивается.

Для решения вышеупомянутых проблем в вариантах осуществления настоящей заявки предлагается вышеуказанный способ.

Управляющая информация определяется данными API открытия возможностей МЕС в форме ключ-значение; управляющая информация сохраняется в субмодуле хранения управляющей информации API, пользователь выбирает диапазон требуемой управляющей информации при подписке на API. После отправки запроса вызова API программа АРР обрабатывает управляющую информацию посредством шлюза API, чтобы реализовать динамическое управление данными API.

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

Способ управления данными API открытия возможностей МЕС, предложенный в вариантах осуществления настоящего изобретения, может быть реализован несколькими следующими модулями: модулем публикации API, субмодулем хранения управляющей информации API, субмодулем хранения информации о подписках API, модулем шлюза API, субмодулем обработки управляющей информации API и модулем предоставления возможностей МЕС.

Как показано на этапах S302-S312 на фиг. 3, модуль предоставления возможностей МЕС обеспечивает реализацию конкретного API возможностей МЕС, например, реализацию API функций определения местоположения пользователя. Для управления возвращаемыми данными API модуль предоставления возможностей МЕС подразделяет полученные данные ответа API в соответствии с диапазоном управления и возвращает разные данные для разных диапазонов. Например, данные ответа API функций определения местоположения пользователя могут управляться в соответствии с параметром области, параметр управления областью может быть определен как площадь, и его словарное значение может быть определено для площади, например размерность управления определяется как три области А, В и С. Для одного API может быть определено множество управляющих размерностей, например, API функций определения местоположения пользователя может также определять размерность управления периодами в дополнение к определению управляющей размерности площади. Словарное значение размерности периода может быть час, день, месяц и т.д. Управляющая размерность и словарное значение вместе называются управляющей информацией API.

Модуль предоставления возможностей МЕС регистрирует API в модуле публикации API. Во время регистрации управляющая информация API передается в виде пары «ключ-значение», и основная цель регистрации API - предоставить вызывающей стороне API URL-адрес записи доступа. В обычном режиме, чтобы контролировать диапазон данных, возвращаемых посетителем, необходимо зарегистрировать различные API, например, указанные выше области А, В и С и три момента времени, включая день и месяц, поэтому необходимо зарегистрировать следующие шесть API:

{apiroot}/location/v1/area/А;

{apiroot}/location/v1/агеа/С;

{apiroot}/location/v1/period/hour;

{apiroot}/location/v1/period/day;

{apiroot}/location/v1/period/month.

В вариантах осуществления настоящего изобретения при регистрации API регистрируется только один API для различной управляющей информации, например, только один API регистрируется для вышеуказанного диапазона управления:

{apiroot}/location/v1/zone.

Кроме того, управляющая информация отправляется в модуль публикации API в качестве дополнительной информации в виде пары «ключ-значение». Например, управляющая информация может быть определена следующим образом:

площадь: А|В|С

период: час|день|месяц.

Как правило, модуль публикации API сохраняет и отображает только URL-адрес записи вызова API. Для обработки управляющей информации API в вариантах осуществления настоящего изобретения субмодуль хранения управляющей информации API и субмодуль хранения информации о подписке на API добавляются в модуль регистрации API. Субмодулю хранения управляющей информации API не требуется значение управляющей размерности и словарного значения API, а требуется только хранить и отображать управляющую информацию, передаваемую модулем предоставления возможностей МЕС.

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

{apiroot}/location/v1/агеа/В;

{apiroot}/location/v1/агеа/С.

В вариантах осуществления настоящего изобретения пользователям API, использующим данные разных диапазонов, предлагается подписываться на один и тот же API и вызывать только его в кодах, например, следующий API:

{apiroot}/location/v1/zone.

Пользователь API выбирает диапазон данных, на который необходимо подписаться, и диапазон данных предоставляется субмодулем хранения управляющей информации API.

Выбранный пользователем диапазон данных хранится в субмодуле хранения информации о подписке на API. Например, если пользователь выбирает данные области В и области С, субмодуль хранения информации о подписке на API сохраняет следующую информацию:

площадь: В|С.

Пользователь также может выбрать диапазоны данных из нескольких размерностей, например, в дополнение к области, пользователь также может выбрать данные временной размерности «день», и в этом случае субмодуль хранения информации о подписке на API хранит управляющую информацию всех размерностей, например:

площадь: В|С

период: день.

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

После получения запроса API, перенаправленного модулем шлюза API, модуль функций должен проанализировать заголовок запроса, чтобы получить содержащуюся в нем управляющую информацию. Поскольку управляющая информация сама по себе определяется модулем функций, он может возвращать разные данные в соответствии с различной управляющей информацией.

Когда пользователю API необходимо изменить диапазон данных, полученный путем вызова API в программе АРР, пользователю API нужно только повторно подписаться на диапазон данных API без изменения кодов программы АРР, чтобы реализовать динамическое управление данными API.

Открытие возможностей МЕС можно разделить на два этапа: первый этап - публикация API возможностей МЕС, а второй этап- вызов API. Эти конкретные этапы реализации вариантов осуществления настоящего изобретения описаны ниже.

На первом этапе выполняется публикация возможностей МЕС, как показано на фиг. 4:

S402, модуль предоставления возможностей МЕС выполняет разделение диапазона управления данными на предоставляемых возможностях. Например, модуль предоставления возможностей МЕС может предоставлять API возможности определения местоположения пользователя. Чтобы управлять диапазоном данных возможности определения местоположения, модуль предоставления возможностей МЕС сначала определяет управляющую размерность данных. Например, проверяет соответствие размерности площади, а затем разделяет данные в соответствии с этой управляющей размерностью. Например, площадь делится между тремя областями А, В и С. Для разных вызывающих API могут быть возвращены данные о местоположении только области А или области В. Для одного API может быть определено множество управляющих размерностей, например, API возможности определения местоположения пользователя может также определять размерность периода в дополнение к определению размерности площади, например, разделять размерность периода на час, день, месяц и т.д.

S404, модуль предоставления возможностей МЕС регистрирует возможности API в модуле публикации API. Когда API зарегистрирован, нет необходимости регистрировать несколько API для данных разных управляющих диапазонов. Необходимо зарегистрировать только один API, а управляющий диапазон данных переносится в дополнительное поле. Например, при регистрации API возможности определения местоположения пользователя необходимо зарегистрировать только один API, как показано ниже:

{apiroot}/location/v1/zone.

Диапазоны управления областями А, В и С отправляются в модуль регистрации API через дополнительные поля. Отправка управляющего диапазона может выполняться в формате «ключ-значение», где ключ - контролируемая размерность, значение -словарное значение элемента контроля, и словарные значения сегментируются с помощью разделителя. Кроме того, чтобы отобразить управляющую информацию в модуле публикации API, также необходимо отправить отображаемую информацию об управляющей размерности и словарном значении в модуль публикации API. Например, управляющая информация, отправляемая API определения местоположения пользователя, может быть определена следующим образом: ключ- «площадь», значение - «А|В|С». Ключ отображается как «выбор области», а значение отображается как «область А|область В|область С». Разделитель значений предварительно согласовывается модулем предоставления возможностей МЕС и модулем публикации API, например, "|" может использоваться в качестве разделителя, при этом "," также может использоваться в качестве разделителя. В приведенном выше примере "|" используется в качестве разделителя. Если один API имеет несколько управляющих размерностей, они все отправляются в модуль публикации API. Например, если API возможности определения местоположения пользователя дополнительно определяет управляющую размерность периода, управляющая размерность времени может быть определена следующим образом: ключ - «период», значение - «час|день|месяц». Ключ отображается как «выбор времени», значение отображается как «час/день/месяц», и эта управляющая размерность одновременно отправляется в модуль публикации API. В таблице 1 приведен пример управляющей размерности и словарного значения одного API.

S406, субмодуль хранения управляющей информации API хранит и отображает всю управляющую информацию API, а управляющая информация, представленная в таблице 1, хранится в этом модуле. Модуль публикации API считывает управляющую информацию из субмодуля хранения управляющей информации API и отображает управляющую информацию. На фиг. 5 представлен пример результат отображения API службы определения местоположения пользователя. В этом примере после отображения URL-адреса API служба определения местоположения пользователя добавляет два управляющих параметра: «выбор области» и «выбор времени», а информация в интерфейсе отображается в формате пары «ключ-значение», отправленной модулем функций.

Для второго этапа этап вызова API и этапы реализации изображены на фиг. 6.

S602, пользователь API подписывается на API, например, API определения местоположения пользователя {apiroot}/location/v1/zone, и выбирает данные из разных диапазонов в соответствии с требованиями. На фиг. 7 представлен пример подписки на сервис определения местоположения пользователя. В этом примере пользователь API выбирает «область В» и «область С» в размерности области и выбирает «день» в размерности времени.

S604, субмодуль хранения информации о подписке на API сохраняет диапазон данных, выбранный пользователем API, и в данном примере хранится следующая информация:

U RL-адpec: {apiroot}/location/v1 /zone

область: В|С

период: день.

S606, после того как пользователь API подписался на API, API получает информацию аутентификации для вызова из модуля публикации, и информация аутентификации может быть представлена ключом API, токеном пользователя и т.д.

S608, программа АРР, разработанная пользователем API, несет информацию аутентификации для отправки запроса вызова в шлюз API, например, отправляет запрос вызова API службы определения местоположения пользователя.

S610, после получения запроса вызова шлюз API отправляет запрос проверки в модуль публикации API, чтобы проверить правильность информации аутентификации.

S612 модуль публикации API проверяет данные аутентификации и возвращает результат шлюзу API.

Если проверка не пройдена, выполняется S614, то есть возвращается сообщение об ошибке вызова. Если вызов передан, выполняется этап S616, то есть шлюз API отправляет запрос в субмодуль обработки управляющей информации API после получения ответного сообщения, указывающего на успешную аутентификацию после проверки модулем публикации API. Субмодуль обработки управляющей информации API запрашивает диапазон данных, на который подписан пользователь API, из субмодуля хранения информации о подписке на API. В этом примере информация, возвращаемая субмодулем хранения информации о подписке на API, выглядит следующим образом:

область: В|С

период: день.

S618, шлюз API добавляет в заголовок запроса информацию, возвращенную субмодулем хранения информации о подписке на API, в качестве управляющей информации. При добавлении заголовка запроса модулем шлюза API правило именования заголовка определяется протоколом HTTP. Имя заголовка может быть определено в формате «ключ размерности х-<управляющая размерность>». В этом примере может быть добавлен следующий заголовок запроса:

х-область: В|С

х-период: день

При этом «х-область» относится к добавлению префикса «х-» перед управляющей размерностью области, «В|С» относится к «области В» и «области С», которые выбираются во время подписки на вызывающий API. «х-период» относится к добавлению префикса «х-» перед управляющей размерностью периода времени, «день» относится к параметру «день», выбранному во время подписки вызывающей стороны API.

S620, после получения запроса API, перенаправленного модулем шлюза, модуль предоставления возможностей МЕС должен проанализировать заголовок запроса «х-», передаваемый шлюзом. В этом примере заголовком запроса является «х-область» и «х-период», и после удаления префикса «х-» модуль функций получает ключ «область» и «период» управляющих размерностей, и значения «В|С» и «день» двух управляющих размерностей. Поскольку эти пары «ключ-значение» определяются модулем функций, этот модуль может возвращать данные в соответствии с этой информацией, и в этом примере возвращаются данные о площади областей В и С, а также данные о времени «день».

С помощью описанного выше процесса данные ответа API автоматически контролируются шлюзом API. Если пользователь API хочет изменить диапазон данных API, полученный в программе АРР, пользователю API не нужно изменять коды программы АРР, а нужно только повторно выбрать подписку на диапазон данных, т.е. выполнить выбор, описанный в первом этапе, а затем полученные данные могут быть динамически изменены в приложении.

По описаниям вышеприведенных вариантов осуществления специалистам в данной области техники очевидно, что способ в соответствии с вышеприведенными вариантами осуществления может быть реализован с помощью программного обеспечения в сочетании с необходимой универсальной аппаратной платформой и также может быть реализован с помощью аппаратных средств, но первое во многих случаях является лучшим вариантом. Основываясь на этом понимании, технические решения настоящего изобретения по существу или в той его части, которая развивает известный уровень техники, могут быть реализованы в виде программного продукта, причем компьютерный программный продукт хранится на носителе данных (например, ПЗУ/ОЗУ, магнитный диск и оптический диск) и включают в себя множество инструкций для указания компьютеризированному устройству (это может быть мобильный телефон, компьютер, сервер или сетевое устройство и т.п.) выполнять способ в различных вариантах осуществления настоящего изобретения.

Настоящий вариант осуществления дополнительно содержит устройство для вызова интерфейса прикладного программирования. Устройство используется для реализации предшествующих вариантов осуществления и предпочтительных вариантов осуществления, и его описание повторно здесь не приводится. Используемый ниже термин «модуль» может подразумевать комбинацию программного и/или аппаратного обеспечения с заранее определенной функцией. Хотя устройство, описанное в следующих вариантах осуществления, предпочтительно реализуется в виде программного обеспечения, также возможны и предполагаются аппаратные реализации или комбинация программного и аппаратного обеспечения.

На фиг. 8 представлена структурная блок-схема устройства вызова интерфейса прикладного программирования согласно варианту осуществления настоящего изобретения. Как показано на фиг. 8, устройство включает следующие компоненты:

первый модуль 802 приема, сконфигурированный для получения запроса вызова первого интерфейса прикладного программирования (API), отправленного целевым приложением, при этом запрос вызова первого API используется для запроса вызова первого API, и запрос вызова первого API содержит первый идентификатор пользователя;

второй модуль 804 приема, сконфигурированный для получения первого диапазона данных первого API с предварительной подпиской первого идентификатора пользователя, при этом первый диапазон данных первого API включает в себя первую целевую размерность в соответствии с первым API и целевой параметр в соответствии с первой целевой размерностью;

третий модуль 806 приема, сконфигурированный для получения данных ответа первого API, соответствующих первому диапазону данных первого API;

первый модуль передачи 808, сконфигурированный для отправки данных ответа первого API в целевое приложение.

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

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

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

Устройство дополнительно включает четвертый модуль приема данных, выполненный с возможностью перед получением запроса вызова первого интерфейса прикладного программирования (API), отправленного целевым приложением, получать первый запрос на подписку для первого идентификатора пользователя, при этом первый запрос на подписку используется для запроса на подписку на первый диапазон данных первого API; и модуль записи, выполненный с возможностью записи первого диапазона данных по подписке первого идентификатора пользователя.

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

Первый модуль приема включает четвертый модуль приема, сконфигурированный для получения запроса вызова первого API, отправленного целевым приложением, посредством кода вызова целевого API. Пятый модуль приема включает пятый модуль приема, сконфигурированный для получения запроса вызова второго API, отправленного целевым приложением посредством кода вызова целевого API.

Устройство дополнительно включает восьмой модуль приема данных, выполненный с возможностью получения второго запроса подписки первого идентификатора пользователя перед этапом получения запроса вызова второго API, отправленного целевым приложением, при этом второй запрос подписки используется для запроса изменения диапазона данных первого API по подписке первого идентификатора пользователя из первого диапазона данных на второй диапазон данных; модуль изменения с возможностью изменения диапазона данных первого API по подписке первого идентификатора пользователя, с первого диапазона данных на второй.

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

Первый модуль приема включает шестой модуль приема, сконфигурированный для получения на шлюзе API запроса вызова первого API, отправленного целевым приложением; второй модуль приема включает седьмой модуль приема, сконфигурированный для получения на шлюзе API первого диапазона данных, хранящегося в субмодуле хранения информации о подписке на API; и третий модуль приема включает модуль обработки, сконфигурированный для добавления на шлюзе API первого диапазона данных в качестве управляющей информации в запрос вызова первого API, чтобы получить запрос вызова третьего API; отправки на шлюзе API третьего запроса вызова API в модуль предоставления возможностей МЕС и получения на шлюзе API данных ответа первого API, отправленных модулем предоставления возможностей МЕС, при этом модуль предоставления возможностей МЕС используется для запроса данных ответа первого API, соответствующих первому диапазону данных.

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

Следует отметить, что вышеупомянутые модули могут быть реализованы с помощью программного или аппаратного обеспечения, и для последнего вышеупомянутые модули могут быть реализованы, например, следующим образом: все вышеупомянутые модули расположены в одном и том же процессоре или вышеуказанные модули расположены в разных процессорах в любых комбинациях.

В соответствии с вариантами осуществления настоящего изобретения дополнительно предоставляется компьютерно-читаемый носитель данных, компьютерная программа хранится на компьютерно-читаемом носителе данных, при этом компьютерная программа сконфигурирована для осуществления шагов в любом из предыдущих вариантов осуществления способа при ее выполнении.

В примерном варианте осуществления компьютерно-читаемый носитель данных может включать в себя без ограничений различные носители, способные хранить компьютерную программу, такие как флэш-диск USB, постоянное запоминающее устройство (Read-Only Memory, сокращенно ROM), оперативное запоминающее устройство (Random Access Memory, сокращенно RAM), мобильный жесткий диск, магнитный диск или оптический диск.

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

В примерном варианте осуществления электронное устройство может дополнительно включать передающее устройство и устройство ввода/вывода, при этом передающее устройство соединено с процессором, и устройство ввода/вывода также соединено с процессором.

Конкретные примеры настоящего варианта осуществления можно найти по ссылкам на примеры, описанные в предшествующих вариантах осуществления, а также примерные варианты осуществления, и поэтому они здесь повторно не описываются.

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

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

Промышленная применимость

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

Группа изобретений относится к области связи и может быть использована для вызова интерфейса прикладного программирования (API). Техническим результатом является обеспечение динамического управления данными ответа API. Способ содержит: получение запроса вызова первого API, отправленного целевым приложением, при этом запрос вызова первого API используется для запроса вызова первого API и содержит первый идентификатор пользователя; получение первого диапазона данных первого API, с предварительной подпиской первого идентификатора пользователя, при этом первый диапазон данных первого API включает в себя первую целевую размерность в соответствии с первым API и целевой параметр в соответствии с первой целевой размерностью; получение данных ответа первого API, соответствующих первому диапазону данных первого API; отправку данных ответа первого API в целевое приложение; при этом когда диапазон данных первого API с предварительной подпиской первого идентификатора пользователя изменяется с первого диапазона данных на второй диапазон данных, получение запроса вызова второго API, отправленного целевым приложением, при этом запрос вызова второго API используется для запроса для вызова первого API, и запрос вызова второго API содержит первый идентификатор пользователя. 4 н. и 9 з.п. ф-лы, 8 ил., 1 табл.

1. Способ вызова интерфейса прикладного программирования, включающий:

получение запроса вызова первого интерфейса прикладного программирования (API), отправленного целевым приложением, при этом запрос вызова первого API используется для запроса вызова первого API, и запрос вызова первого API содержит первый идентификатор пользователя;

получение первого диапазона данных первого API, с предварительной подпиской первого идентификатора пользователя, при этом первый диапазон данных первого API включает в себя первую целевую размерность в соответствии с первым API и целевой параметр в соответствии с первой целевой размерностью;

получение данных ответа первого API, соответствующих первому диапазону данных первого API; и

отправку данных ответа первого API в целевое приложение;

при этом когда диапазон данных первого API с предварительной подпиской первого идентификатора пользователя изменяется с первого диапазона данных на второй диапазон данных, получение запроса вызова второго API, отправленного целевым приложением, при этом запрос вызова второго API используется для запроса для вызова первого API, и запрос вызова второго API содержит первый идентификатор пользователя.

2. Способ по п. 1, отличающийся тем, что этап получения данных ответа первого API, соответствующих первому диапазону данных первого API, включает:

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

3. Способ по п. 1, отличающийся тем, что этап получения данных ответа первого API, соответствующих первому диапазону данных первого API, включает:

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

4. Способ по п. 1, отличающийся тем, что этап получения данных ответа первого API, соответствующих первому диапазону данных первого API, включает:

получение данных ответа API, которые получены первым сервисом API, предоставляемым первым API, в соответствии с целевым параметром первой целевой размерности, при этом данные ответа первого API включают в себя полученные данные ответа API.

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

получение первого запроса подписки для первого идентификатора пользователя, при этом первый запрос подписки используется для запроса подписки на первый диапазон данных первого API;

запись первого диапазона данных по подписке первого идентификатора пользователя.

6. Способ по п. 1, в котором после получения запроса вызова второго API, отправленного целевым приложением, способ дополнительно включает:

получение второго диапазона данных первого API с предварительной подпиской первого идентификатора пользователя, при этом второй диапазон данных первого API включает в себя вторую целевую размерность в соответствии с первым API и целевой параметр в соответствии со второй целевой размерностью;

получение данных ответа второго API, соответствующих второму диапазону данных первого API;

отправку данных ответа второго API в целевое приложение.

7. Способ по п. 6, отличающийся тем, что

этап получения запроса вызова первого интерфейса прикладного программирования (API), отправленного целевым приложением, включает получение запроса вызова первого API, отправленного целевым приложением, посредством кода вызова целевого API; и

этап получения запроса вызова второго API, отправленного целевым приложением, включает: получение запроса вызова второго API, отправленного целевым приложением, посредством кода вызова целевого API.

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

получение второго запроса подписки первого идентификатора пользователя, при этом второй запрос подписки используется для запроса изменения диапазона данных первого API, на который подписан первый идентификатор пользователя, с первого диапазона данных на второй диапазон данных;

изменение диапазона данных первого API, на который подписан записанный первый идентификатор пользователя, с первого диапазона данных на второй диапазон данных.

9. Способ по любому из пп. 1–8, отличающийся тем, что перед этапом получения запроса вызова первого интерфейса прикладного программирования (API), отправленного целевым приложением, способ дополнительно включает:

регистрацию первого API, при этом первый API доступен для вызова после регистрации; и

запись размерности, которая доступна для выбора в первом API, и параметра, который доступен для выбора в соответствии с размерностью, которая доступна для выбора, при этом размерность, которая доступна для выбора, включает в себя первую целевую размерность, и параметр, который доступен для выбора, включает в себя целевой параметр.

10. Способ по любому из пп. 1-8, отличающийся тем, что

этап получения запроса вызова первого интерфейса прикладного программирования (API), отправленного целевым приложением, включает: получение, на шлюзе API, запроса вызова первого API, отправленного целевым приложением;

этап получения первого диапазона данных первого API с предварительной подпиской первого идентификатора пользователя включает: получение, на шлюзе API, первого диапазона данных, хранящегося в субмодуле хранения информации о подписке API; и

этап получения данных ответа первого API, соответствующих первому диапазону данных первого API, включает: добавление, на шлюзе API, первого диапазона данных в качестве управляющей информации в запрос вызова первого API, чтобы получить запрос вызова третьего API; отправку, на шлюзе API, запроса вызова третьего API в модуль предоставления возможностей MEC; и получение, на шлюзе API, данных ответа первого API, отправленных модулем предоставления возможностей MEC, при этом модуль предоставления возможностей MEC используется для запроса данных ответа первого API, соответствующих первому диапазону данных.

11. Устройство для вызова интерфейса прикладного программирования, содержащее:

первый модуль приема, сконфигурированный для получения запроса вызова первого интерфейса прикладного программирования (API), отправленного целевым приложением, при этом запрос вызова первого API используется для запроса вызова первого API, и запрос вызова первого API содержит первый идентификатор пользователя;

второй модуль приема, сконфигурированный для получения первого диапазона данных первого API с предварительной подпиской первого идентификатора пользователя, при этом первый диапазон данных первого API включает в себя первую целевую размерность в соответствии с первым API и целевой параметр в соответствии с первой целевой размерностью;

третий модуль приема, сконфигурированный для получения данных ответа первого API, соответствующих первому диапазону данных первого API; и

первый модуль передачи, сконфигурированный для отправки данных ответа первого API в целевое приложение;

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

12. Компьютерно-читаемый носитель данных, при этом на компьютерно-читаемом носителе данных хранится компьютерная программа, и компьютерная программа сконфигурирована для осуществления способа по любому из пп. 1–10 при выполнении.

13. Электронное устройство для вызова интерфейса прикладного программирования, включающее память и процессор, в котором компьютерная программа хранится в памяти, и процессор сконфигурирован для выполнения компьютерной программы, чтобы осуществлять способ по любому из пп. 1–10.