Перейти к содержимому

Фотография

Что такое API?


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 7

#1 Kukuh

Kukuh

    Новый участник

  • Members
  • Pip
  • 35 сообщений
  • ФИО:Рябчук Максим Олександрович

Отправлено 30 марта 2020 - 16:57

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

В моем понимании, API - это набор функций. Апи может быть как одно, так и несколько, в каждом Апи есть n-ное количество функций. 

То есть, получается, что тестирование API - это, в каком-то роде, интеграционное функциональное тестирование(или просто функциональное тестирование(если рассматривать функционал в одном Апи)? 

Интеграционное тестирование, я имею ввиду, что мы тестируем взаимодействие между Апи созданым нашим разработчиком и инным, с которым разработчик установил взаимодействие, что бы не писать с нуля и не тратить свое время. (Пример из видео: сайт кинотеатра(наш Апи) имеет взаимодействие с платежной системой(не наш Апи).

Am i right?


  • 0

#2 e_white

e_white

    Новый участник

  • Members
  • Pip
  • 4 сообщений
  • ФИО:Евгений Белый

Отправлено 02 апреля 2020 - 10:06

Привет!

На конференциях часто слышу термин "крутить ручки". Т.е. дергать те или иные АПИшки. Этот оборот очень хорошо раскрывает то, как работает АПИ.

Детальнее: Бэкенды пишут бэк. Фронты пишут фронт. Вторым нужно что-то, через что можно общаться с бэком, т.е. слать/получать/изменять/удалять данные.

Для этого нужен какой-то интерфейс. API(endpoint) - и есть такой интерфейс(Application Programming Interface).

 

Так как все нагляднее на примерах, вот два варианта АПИ с внешними интерфейсами("ручками" торчащими наружу:)

1. Всеми нами любимый пример - автомобиль.

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

 

Но это закрытое АПИ. Что тогда тут будет внешний интерфейсом?

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

 

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

 

2. Интеграция почтовых сервисов и онлайн магазинов(по аналогии с кинотеатром и платежкой).

Думаю все мы когда-то заказывали что-то онлайн, и в конце указывали отделение почты, куда бы ты хотел оформить доставку. Так вот вопрос? Откуда эти онлайн магазины знают всю информацию о всех почтовых отделениях, их адресах, названиях, актуальном списке, ведь они все время меняются? Не нанимать же онлайн магазину специального человека, который будет сидеть и актуализировать эту информацию? Конечно нет:)

 

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

 

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

 

Зачем нам тестировать АПИ?

Чтобы удостовериться, правильно ли работают "ручки", используемые внешними модулями. Так как АПИ - это по сути JSON схемы, они должны быть правильно описаны. Если схема говорит, что поле принимает int или bool, значит нужно проверить, что это так и есть. Это очень кратко. Тема тестирования АПИ это совсем отдельный разговор :)

 

 

Что касается интеграционного тестирования.

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


  • 1

#3 Kukuh

Kukuh

    Новый участник

  • Members
  • Pip
  • 35 сообщений
  • ФИО:Рябчук Максим Олександрович

Отправлено 02 апреля 2020 - 12:11

Привет!

На конференциях часто слышу термин "крутить ручки". Т.е. дергать те или иные АПИшки. Этот оборот очень хорошо раскрывает то, как работает АПИ.

Детальнее: Бэкенды пишут бэк. Фронты пишут фронт. Вторым нужно что-то, через что можно общаться с бэком, т.е. слать/получать/изменять/удалять данные.

Для этого нужен какой-то интерфейс. API(endpoint) - и есть такой интерфейс(Application Programming Interface).

 

Так как все нагляднее на примерах, вот два варианта АПИ с внешними интерфейсами("ручками" торчащими наружу:)

1. Всеми нами любимый пример - автомобиль.

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

 

Но это закрытое АПИ. Что тогда тут будет внешний интерфейсом?

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

 

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

 

2. Интеграция почтовых сервисов и онлайн магазинов(по аналогии с кинотеатром и платежкой).

Думаю все мы когда-то заказывали что-то онлайн, и в конце указывали отделение почты, куда бы ты хотел оформить доставку. Так вот вопрос? Откуда эти онлайн магазины знают всю информацию о всех почтовых отделениях, их адресах, названиях, актуальном списке, ведь они все время меняются? Не нанимать же онлайн магазину специального человека, который будет сидеть и актуализировать эту информацию? Конечно нет:)

 

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

 

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

 

Зачем нам тестировать АПИ?

Чтобы удостовериться, правильно ли работают "ручки", используемые внешними модулями. Так как АПИ - это по сути JSON схемы, они должны быть правильно описаны. Если схема говорит, что поле принимает int или bool, значит нужно проверить, что это так и есть. Это очень кратко. Тема тестирования АПИ это совсем отдельный разговор :)

 

 

Что касается интеграционного тестирования.

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

Окей, тогда тестирование АПИ ( как я понял ) - тестирование конкретного модуля и, в каком-то роде, это тестирование бэкэнда.

То есть, если брать к примеру автомобиль, то тут будет два тестирования АПИ - АПИ двигателя и АПИ всего остального.

В случае онлайн-магазинов это будет тестирование АПИ подсказок адресов, тестирование АПИ платежной системы и тестирование АПИ конкретно нашего сайта.

Верно?


  • 0

#4 e_white

e_white

    Новый участник

  • Members
  • Pip
  • 4 сообщений
  • ФИО:Евгений Белый

Отправлено 02 апреля 2020 - 12:48

Окей, тогда тестирование АПИ ( как я понял ) - тестирование конкретного модуля и, в каком-то роде, это тестирование бэкэнда.

 

 

И да и нет.

Это не будет исчерпывающим тестированием бэкенда, но это есть тестирование интерфейсов бэкенда.

 

Другими словами, если вас спросят, что вы проверили, тестируя ваше внутреннее АПИ, вы:

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

- но НЕ сможете сказать, что весь бэкенд работает верно. Опять же по аналогии с автомобилем, у вас на приборке может быть все ок, но при этом могут подтекать стойки, масло, и так далее. Тут уже нужен более глубокий осмотр, конкретно открывать капот и лезть смотреть конкретные узлы(писать юнит тесты).

 

 

То есть, если брать к примеру автомобиль, то тут будет два тестирования АПИ - АПИ двигателя и АПИ всего остального.

 

 

Не уверен, что можно говорить о таком разделении.

АПИ - это не что-то, что генерируется само исходя из написанного кода(хотя и так тоже бывает). Это ровно те "ручки", которые спланированы в приложении для требуемого взаимодействия с внешними модулями. 

 

 

В случае онлайн-магазинов это будет тестирование АПИ подсказок адресов

 

 

Если это конкретная внешняя апишка, которая возвращает список адресов почты, то да. Тестируя тут вы должны проверить:

1. Что вы правильно обрабатываете полученные от почты данные у себя на стороне(формат данных, список полей и тд). Это в том числе является объектом тестирования - как вы работаете с внешними АПИ.

2. Пункт более спорный, но можете проверить что вам приходит все что нужно, если список адресов является конечным. Спорный потому что логика эта лежит у них на стороне, и если придет на один адрес больше или меньше, вы ничего не сможете с этим сделать и не узнаете, баг это или нет.

 

 

тестирование АПИ платежной системы

 

 

Надо понимать, что внешние АПИ как таковые тестировать не надо. Это полноценный инструмент(third-part) других компаний, который уже протестирован их специалистами, и если вы имеете к нему доступ, значит он уже "в проде". Тем более что такие комплексные решения как платежные системы - это немного другое. Вы можете встроить их себе в приложение, да, но из-за соображений безопасности основная их работа часто происходит у них на стороне. Опять таки повторюсь, здесь я бы проверял больше не их работу, а то, что вы предоставляете все что им нужно для корректной работы и в правильном формате. А уж они, если они внешние и достоверные, скорее всего работают правильно :)


  • 0

#5 Kukuh

Kukuh

    Новый участник

  • Members
  • Pip
  • 35 сообщений
  • ФИО:Рябчук Максим Олександрович

Отправлено 02 апреля 2020 - 18:18

То есть, нам не обязательно проводить негативное тестирование внешного АПИ, достаточно удостовериться, что все работает правильно? Сложно ли понять на практике, где наш АПИ, а где сторонний?


Вы так четко все объясняете. Курсы ведете какие-то?)
  • 0

#6 e_white

e_white

    Новый участник

  • Members
  • Pip
  • 4 сообщений
  • ФИО:Евгений Белый

Отправлено 03 апреля 2020 - 14:43

То есть, нам не обязательно проводить негативное тестирование внешного АПИ, достаточно удостовериться, что все работает правильно?

 

 

Давайте еще раз убедимся что понимаем друг друга верно:

  1. Ваше внутреннее АПИ - это ендпоинты, предназначенные для работы внутри вашего приложения --- Тестировать важно
    1. Проверяется работоспособность АПИ внутри вашего приложения
  2. Ваше внешнее АПИ - это ендпоинты, предназначенные для работы с вашим приложением извне(например, если почта или платежная система, это вы) --- Тестировать очень важно
    1. Проверяется работоспособность АПИ как внутри вашего приложения, так и с приложениями извне. Вы должны убедиться, что системы извне могут успешно работать с вашими "ручками", при этом не имея возможность навредить вашей системе или получить закрытую информацию.
  3. Публичное АПИ(не ваше, то есть АПИ почты. кинотеатра, платежной системы, и тд, которые вы как-то используете) - это ендпоинты third-part системы, предназначенные для использования в каких-то целях --- Как правило не тестируется
    1. Потому что это third-part система, а их не тестируют. Вы ж Джиру или Гит не тестируете :)
Сложно ли понять на практике, где наш АПИ, а где сторонний?

 

 

Как правило на проектах используется какой-то инструмент для документирования API(такие как Swagger, например), который позволяет увидеть все ваши ендпоинты, их схемы и используемые модели. А сторонний АПИ, ну, он вам не принадлежит, и не входит в список ваших апишек, так что думаю да, разработчики ваши с этим трудностей испытать не должны :)

 

Вы так четко все объясняете. Курсы ведете какие-то?)

 

 

Нет, просто работаю в этой теме и интересуюсь :)


  • 0

#7 e_white

e_white

    Новый участник

  • Members
  • Pip
  • 4 сообщений
  • ФИО:Евгений Белый

Отправлено 03 апреля 2020 - 14:45

 

То есть, нам не обязательно проводить негативное тестирование внешного АПИ, достаточно удостовериться, что все работает правильно?

 

 

Давайте еще раз убедимся что понимаем друг друга верно:

  1. Ваше внутреннее АПИ - это ендпоинты, предназначенные для работы внутри вашего приложения --- Тестировать важно
    1. Проверяется работоспособность АПИ внутри вашего приложения
  2. Ваше внешнее АПИ - это ендпоинты, предназначенные для работы с вашим приложением извне(например, если почта или платежная система, это вы) --- Тестировать очень важно
    1. Проверяется работоспособность АПИ как внутри вашего приложения, так и с приложениями извне. Чтобы системы извне могли успешно работать с вашими "ручками", при этом не имея возможность вам навредить или получить закрытую информацию
  3. Публичное АПИ(не ваше, то есть АПИ почты. кинотеатра, платежной системы, и тд, которые вы как-то используете) - это ендпоинты third-part системы, предназначенные для использования в каких-то целях --- Как правило не тестируется
    1. Потому что это third-part система, а их не тестируют. Вы ж Джиру или Гит не тестируете :)
Сложно ли понять на практике, где наш АПИ, а где сторонний?

 

 

Как правило на проектах используется какой-то инструмент для документирования API(такие как Swagger, например), который позволяет увидеть все ваши ендпоинты, их схемы и используемые модели. А сторонний АПИ, ну, он вам не принадлежит, и не входит в список ваших апишек, так что думаю да, разработчики ваши с этим трудностей испытать не должны :)

 

Вы так четко все объясняете. Курсы ведете какие-то?)

 

 

Нет, просто работаю в этой теме и интересуюсь :)

 


  • 0

#8 Kukuh

Kukuh

    Новый участник

  • Members
  • Pip
  • 35 сообщений
  • ФИО:Рябчук Максим Олександрович

Отправлено 19 мая 2020 - 22:04

 

 

То есть, нам не обязательно проводить негативное тестирование внешного АПИ, достаточно удостовериться, что все работает правильно?

 

 

Давайте еще раз убедимся что понимаем друг друга верно:

  1. Ваше внутреннее АПИ - это ендпоинты, предназначенные для работы внутри вашего приложения --- Тестировать важно
    1. Проверяется работоспособность АПИ внутри вашего приложения
  2. Ваше внешнее АПИ - это ендпоинты, предназначенные для работы с вашим приложением извне(например, если почта или платежная система, это вы) --- Тестировать очень важно
    1. Проверяется работоспособность АПИ как внутри вашего приложения, так и с приложениями извне. Чтобы системы извне могли успешно работать с вашими "ручками", при этом не имея возможность вам навредить или получить закрытую информацию
  3. Публичное АПИ(не ваше, то есть АПИ почты. кинотеатра, платежной системы, и тд, которые вы как-то используете) - это ендпоинты third-part системы, предназначенные для использования в каких-то целях --- Как правило не тестируется
    1. Потому что это third-part система, а их не тестируют. Вы ж Джиру или Гит не тестируете :)
Сложно ли понять на практике, где наш АПИ, а где сторонний?

 

 

Как правило на проектах используется какой-то инструмент для документирования API(такие как Swagger, например), который позволяет увидеть все ваши ендпоинты, их схемы и используемые модели. А сторонний АПИ, ну, он вам не принадлежит, и не входит в список ваших апишек, так что думаю да, разработчики ваши с этим трудностей испытать не должны :)

 

Вы так четко все объясняете. Курсы ведете какие-то?)

 

 

Нет, просто работаю в этой теме и интересуюсь :)

 

 

Когда я вел с вами эту беседу - еще очень мало знал об API.

Сейчас я пересмотрел множество видеоуроков и уже примерно понял что и к чему. Спасибо вам большое за то, что уделили мне своё время :)


  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных